Tyson

I think Cody's fix from the other thread should be update /app/models/clients.php (line 89): $this->setCustomField($field->name, $client_id, isset($vars['custom']) && array_key_exists($field->name, $vars['custom']) ? $vars['custom'][$field->name] : null); to $this->setCustomField($field->id, $client_id, isset($vars['custom']) && array_key_exists($field->id, $vars['custom']) ? $vars['custom'][$field->id] : null);

Sounds like a bug with how the order form passes custom field values for validation. I believe custom fields are validated one at a time, so even if all of them are erroneous, only the first error would show.

Sounds like roundcube takes 5 minutes to update your inbox with new messages.

That would be the way to go in this case. Automatic changes are often seen as unexpected and undesired, so I'm curious to hear what others think about this. If a client opens a ticket from the client area, it's in the system instantly. If you're viewing the tickets listing in the admin area, you wait no more than 30 seconds for the ajax request to fetch new/updated tickets.

This looks like a different error than your OP. Are there any module logs under [Tools] -> [Logs] for Namecheap? They may be useful in figuring out why Namecheap is returning errors.

CORE-517 for v3.0.0.b4 already added the ability for a ticket "Awaiting Reply" to be changed to "Open" automatically when a client replies. Replying as an admin does not change status automatically because you have the option to change it yourself. A conflict may arise if, say, the system automatically changes a ticket whose status is "In Progress" to "Open" if it was not desired. e.g. if an admin changes the status from "Open" to "In Progress", and replies to the ticket only to find that it is back to "Open" again. The time intervals are set in the core, so the support plugin wouldn't specify its own, but I see what you mean. A shorter time may be better, but you may want to try ticket piping instead. Where would this appear?

I've added this as CORE-688 and we'll take a look at the import issue. The tax number will be shown on invoices regardless of whether tax is enabled for a client. I believe this is the intended purpose, especially considering the laws necessitating behavior in some european countries.

I'm curious what the module log says about this response. I can only imagine receiving that error from Plesk if you are attempting to update a customer, but the customer does not exist in Plesk. You can send me a private message with login access and I'll take a look.

Can you put some context to that module response? What requests precede that one (especially the one immediately before)? Feel free to omit sensitive information if you copy/paste it here. Were you trying to create a new service in the interface or update an existing one?

Did you make any modifications to the markup/css prior to your fix? It seems to act as if it's not contained within <section class="pad content"> ... </section> I'm not able to duplicate in Chrome.

This happens when adding a new service? It sounds like your Plesk server is complaining about the data type it received for the webspace/subscription ID. We've tested this on Plesk v11.5 and haven't experienced this issue, so I wonder why Plesk complains about the data type for an empty string now. If you're familiar with php, you can edit /components/modules/plesk/plesk.php and change: $data = array('id' => $webspace_id); to $data = array('id' => (empty($webspace_id) ? null : $webspace_id)); and let us know if that resolves your issue.

Go to [settings] -> [Emails] -> and click to edit "Invoice Delivery (Unpaid)". Paste the contents of the HTML and text versions of the email template here. Your error points to a missing {% endfor %} tag, and sanetcy's solution should resolve it:

Closing as not a bug.

Thanks for stepping through and describing the process. Yes, that is how you would setup language-based payment types. Closing thread as not a bug.

I'm not sure what you mean by this. Proper context is not attainable without seeing it while in Blesta, however, the translator will show the language term and message type to add what little context is available.

This is not a bug. If you read the tooltip next to the language checkbox when adding/editing a payment type, it will say that you should only check that box if you added the name to the language file. The language file is /languages/en_us/_custom.php. The same goes for custom fields and contact types. You'll need to either add the name to the language file, or edit the payment type and uncheck that box.

sanetcy's solution should solve this issue. The email template needs to be syntactically correct. You can review the documentation to help with using tags in email templates.

The cron will automatically close paid invoices, assuming you have it setup to run.

Fixed in CORE-671 for v3.0.1.

Can you compare the content in blesta-new.php with blesta.php? What are the differences, if any? What OS and version of PHP are you running?

This seems to come up a lot. It's important to follow the instructions on installing Blesta and navigate your browser to where you've installed Blesta at /install. e.g. yourdomain.com/install yourdomain.com/billing/install

I'm not able to duplicate this issue. Can you provide more information as described in How to Report a Bug, particularly the steps to duplicate the issue.

Check your Service Creation email template. What tags are you using? If you use no tags, does the error go away? I suspect you are using a tag incorrectly. The documentation might help.

Closing thread as not a bug.

I believe that is a caching issue. If you refresh a few times, do the buttons go back to being next to each other?