Tyson

#8? Client info is shown as: Name Company Address 1 Address 2 City, State Zip Country

FYI, the ticket tags available to email templates are outlined in the Support Manager documentation. Email notifications are based on what the staff members have set for their schedule and the ticket priority settings under the [support] -> [staff] -> [Edit]. Checking the boxes for "Emergency", "Critical", etc. will enable that staff member to receive notifications for tickets opened with those priorities. And staff will only receive an email if a ticket comes in between their scheduled start/end time.

An iframe might work, but Blesta currently only uses the /default/ theme, and would ignore the attempted use of other theme directories under /app/views/client/. However, we plan to add support for multiple theme templates soon.

Did you copy/paste content into the WYSIWYG? Check the Source section to make sure the tags are correct. Also, see this thread. Use the currency_format filter when displaying the tag to perform formatting. A better example might help.

VNC credentials are shown so that the user can use them to login to the server from an application on their computer. Some modules have support for displaying a java applet to login to the console from that page, but this one doesn't.

If you think this is a bug, then please provide additional details as described in How to Report a Bug.

I was able to replicate this issue in Firefox 27. It seems to be a rather strange issue either isolated to Firefox, or how Firefox interprets jquery/javascript cloned fields. I haven't looked into the cause yet, but I've added CORE-1079 so we can look into it further. Other browsers appear unaffected. If you want to add an additional phone number for a client where the Type is "Phone" or the Location is "Home", then you can work around this issue by changing the values twice. i.e. Change the Type from "Phone" to "Fax", then back to "Phone"; and change the Location from "Home" to "Work" and then back to "Home". Firefox will then submit the fields correctly and you won't experience the OP's error.

Not all of the fields on the registration form are required (essentially just name and email), although it may not be clear which those are on that page. We have plans to allow fields to be made optional/hidden as described in CORE-547, but that feature is still pending. Currently, if you really needed to remove those fields, you would need to update the appropriate order plugin registration template to do so in your own copy of Blesta. You can add additional fields, like a checkbox, by creating a custom field under [settings] -> [Company] -> [Client Custom Fields]. The fields will then appear on the registration form if they are assigned to the same client group as the registration form. To tie your custom field to an action, you will need to create a custom plugin. Such a plugin could tie into the Clients.create event to check whether the custom field is set when the client registers, and then perform any logic necessary to interface with your newsletter API.

The cron provisions services after they have been paid for. If you take an offline payment, you can mark the invoice paid once they pay via your offline payment method, and the cron will take care of it afterward.

You may actually continue to exprience this issue if a multi-byte character is where the string splits. Similarly, if this occurs on the support ticket listing page, the ticket listing may fail to load via AJAX (after 30 seconds of viewing the page), leaving the ticket listing blank. We're aware of that and will likely have a fix for the release after v3.1.2.

Your solution makes several changes that I'm not sure are necessary, particularly removing support for Markdown from ticket replies. I've added CORE-1074 to investigate the issue.

Can you provide steps to duplicate the issue? We need to know what settings you have configured, then what data you changed that resulted in the error. For example, what module are you using on the package? How many pricing options do you have setup? Which fields did you change? What values were the fields before and after? etc. The more details you can provide, the better chance we have of determining the cause.

Pages like the main client page make ajax requests to load widgets, and your structure change is probably causing those to return only their template. There may also be missing javascript files necessary in those templates that may be contributing to that as well. Typically, you create a view that can or cannot support its content via ajax, and the controller makes this determination based on whether the request was made via ajax.

The transaction was recorded in BitPay or in Blesta? Per the BitPay module documentation, Blesta will not update the status until BitPay confirms the payment has completed, which is usually about an hour. Did this ever get marked completed? If not, what do the gateway logs say?

Thanks for the steps to duplicate. I've replicated and resolved the issue in CORE-1070 for v3.1.2. If you want to pre-patch this fix yourself, then Update /app/views/admin/default/admin_tools_logemail.pdt (line 40): if (strlen($summary) > 40) $summary = substr($summary, 0, 40) . "..."; ?> <td><?php $this->Html->_($summary);?></td> to: $truncate = (strlen($summary) > 40); $summary = substr($summary, 0, 40) . ($truncate ? "..." : ""); ?> <td><?php echo $summary;?></td> If you can replicate the other issue you mentioned, feel free to create another bug report thread.

Services remain pending until the invoice they are attached to has been paid (or you manually activate them anyway). Only then does the cron attempt to provision it. Unless there is an error of some kind preventing the service from being provisioned, that is how it would work. Thanks for the step-by-step. I'll look into that as soon as I can.

Please provide more information as described in How to Report a Bug. What are the steps to duplicate this issue? Does it only occur with emails sent from the Support Manager? Does this only occur with the body text, or with the subject/html as well? Does this also occur in the client mail log? As for the other issue, the ticket hash code is required to reply to a ticket via email. If it does not match, a bounce is sent because the reply could not be added. A bounce may also be sent if the support department does not allow tickets from non-clients, and the person sending the email is not a client. If you remove the hash code altogether, a new ticket will be created instead. If you want to allow replies by non-clients, then update the support department and uncheck "Allow only clients to open or reply to tickets".

That sounds like an issue with tags in the email template, e.g. {invoice}. My guess is the account was created in Interworx, but the email was simply not sent. Did you make recent changes to an email template to change tags? Maybe you copied+pasted content into the WYSIWYG? This thread may help you fix that issue. I wouldn't think so, especially since it has worked for you in some instances. It may be that the service is added "In Review" for you. In my tests, the service is added as Pending, and Blesta manually or automatically provisions it via the API by creating the account, not modifying it. That may be why it is not working for you, as it is attempting to modify an existing account (which doesn't exist) rather than creating it. I don't see anywhere in the logic that would result in attempting to modify the account unless you went to manage the service and tried to save service details before the account was created. What happens after you order a service as a client under the order form? Do you let the cron provision it, or do you go into the admin interface and attempt to do it yourself? I need to know exactly what you're doing, step-by-step (and as detailed as you can be), in order to duplicate the problem. At what point does the service get placed into "In Review" status?

Fixed in v3.1.2.

This has been fixed.

The first lines that contain "createAccount" or "modifyAccount" simply say what method is being called to make the API request. I can't find much information regarding that error from Interworx, so it may take some time to determine what's going on here. I've just provisioned several Interworx accounts without incident, so all seems well on my end. You mentioned that creating an account works fine, but it errors out when modifying the account. You only modify the account when you go to save updates to an existing account through the admin interface--not in the client interface or via an order form. Ordering a service via the order form will add it as a pending service in Blesta, and you can either provision it manually as an admin, or the cron will provision it automatically when it has been paid for. In either case, the "createAccount" action takes place. Could you clarify what you were doing (and what page(s) you were on) when you received that error message?

What required fields are you referring to that allow you to proceed even when they're empty? We didn't initially write the module, but we'll maintain it, so you can create a bug report about this issue.

No, the email templates display all languages that are installed. And by 'installed', I mean that you have to install them through the admin interface. If I recall correctly, you mentioned in another thread that you updated the database directly to add an entry for en_au. While that is necessary, it's not sufficient, as additional email templates must be generated for the language when initially installed. You should change your default language to English, US, then uninstall the English, AU language from under [settings] -> [Company] -> [General] -> [internationalization], and finally install it properly through the interface on that same page.

Indeed, "domain.com/clients" is not a valid hostname. I suspect that when you set the correct hostname the {payment_url} tag, along with most others, will work as expected.

What do you mean by this? When you create an invoice, or one is created automatically, so long as the cron task is enabled and the email template is enabled, the email is sent at the next cron task interval. You should be able to check the cron logs for the Deliver Invoices task to see if there are any issues.