Tyson

Memory from a package option overrides the memory you have set on the package. If package memory is 1024 MB, adding 1 GB would require selecting the package option 2048 MB.

The date shown in the database is always going to be different than the date shown in the UI unless you're in the UTC timezone. The database dates are all UTC. You mentioned auto-debit runs at 9am MST, which is -7 UTC, so invoices auto-debited would be closed at 16:00 UTC. The dates you mentioned are. Bill Date: February 8, 2016, 7am MST Date Due: February 15, 2016, 11pm MST Date Closed: February 15, 2016, 9am MST Bill Date: February 10, 2016, midnight MST Date Due: February 17, 2016, midnight MST Date Closed: February 16, 2016, 9am MST The time of day invoices are due don't have much of a bearing on the auto-debit since it looks at the entire day to find invoices. It could be throwing things off if the timezone conversion comparison is incorrect. If you look at more examples, do you see consistent behavior for invoices whose due date time is between 00:00:00 and 06:59:59 (in the database) being auto-debited the same day, and otherwise auto-debited the day before if the time is 07:00:00 or greater?

The OP asked about addons, which are a bit different than package options. For package options, you have those available in the $service passed to the tab as $service->options. Because each option can be ordered at the time a service is added, when it renews, or any time in between, you couldn't necessarily know whether the particular option has been paid.

I'm not sure I understand. Can you clarify what you're intending to do?

Can you clarify? I'm not sure which email template you're referring to or which URL you are seeing compared to what it should actually be.

Dedicated IPs would need to be set on the module. Take a look at the documentation. You define each dedicated IP and its associated daemon when you manage the module under [settings] -> [Modules] -> (Manage) -> (Edit). Whenever someone orders a dedicated IP, one from the list will be assigned.

It sounds like your web server's document root for your clients subdomain is actually /home/user/public_html/clients/ rather than /home/user/public_html/, so I suspect appending /clients/ to your Root Web Directory setting will resolve the URL issue for emails sent by cron via CLI.

If you want to update the cPanel module again, same file as mentioned above, find and change this line: 'domain' => isset($vars['cpanel_domain']) ? $vars['cpanel_domain'] : null, to: 'domain' => isset($vars['cpanel_domain']) ? strtolower($vars['cpanel_domain']) : null, I think that would take care of it.

That error is defined in a module. I assume cPanel is what you're using? You could update the regex that it is using to make it case-insensitive if you'd like, i.e., update /components/modules/cpanel/cpanel.php find: "/^([a-z0-9]|[a-z0-9][a-z0-9\-]{0,61}[a-z0-9])(\.([a-z0-9]|[a-z0-9][a-z0-9\-]{0,61}[a-z0-9]))+$/" change to: "/^([a-z0-9]|[a-z0-9][a-z0-9\-]{0,61}[a-z0-9])(\.([a-z0-9]|[a-z0-9][a-z0-9\-]{0,61}[a-z0-9]))+$/i" and try again. I'm not sure how cPanel will respond to the request for a domain with capital letters. It's possible they may reject it on their end, in which case you would need to make the domain lower case before sending.

I was suggesting testing the invoice templates because they can be sent manually via web as well as automatically via cron in CLI, which can be useful in determining whether there is a difference in the construction of the URL between the two methods, indicating a potential issue with the root web directory setting. Since the invoice templates construct the payment URL identically to the late notices, the same result should be expected for both templates when sent via cron. If you're positive that the payment URLs differ between the late notices and unpaid invoice templates when sent via cron, then there is some other issue causing it that is unexpected, such as custom code changes that reset the configured company's hostname at run-time. But that seems unlikely. In such a case, it may be simpler to programmatically debug the cron to determine where the difference is coming from. You mentioned that the incorrect URL is constructed as domain.com/clients/client/pay/... rather than domain.com/client/pay/... -- is Blesta installed in a /clients/ directory on the server? Is there a subdomain setup for Blesta? Are there rewrite rules defined in an .htaccess file to perform redirects related to Blesta? Is Blesta installed in a virtual directory (does the physical path to Blesta differ from the virtual path the web server uses)?

The cron does use the same payment URL for late notices as well as unpaid invoices that it sends, so your issue is strange if the resulting URL differs. The problem with URLs being incorrect usually comes down to two criteria: The Root Web Directory is not set to the correct path. Because of this, URLs in emails sent via cron are incorrect. The email template itself has set the wrong tag/URL. All emails will have an incorrect URL. You just mentioned your Root Web Directory being set to /home/user/public_html/, which looks correct to me. If you're sure that all of the email templates have the correct URLs set in both the HTML and Text versions of the template, then you'll have to narrow down which templates are affected. I would test the following: - Find a recent 'Unpaid Invoice' email from the client's mail log that you know was sent to them via cron from the command line (not from you running the cron manually from Blesta). Make a note of the payment URL. - Find that same invoice on the client's profile page, check the box next to it, and send it to yourself. Then make a note of the payment URL. You will need to look at the Text version of the email in your mail application instead of the HTML version to get an accurate comparison. Are the payment URLs identical between HTML and Text, as well as with the email from the client's mail log?

No, that wouldn't work. The payment URL's are constructed identically. The difference leads me to believe that the issue is with the cron caused by your Root Web Directory setting. See my other post regarding this issue.

Does the service/transaction search from the search bar not suffice for finding the data you're looking for?

The task I mentioned above describes the issue as a limit on the service quantity field, which is fixed pending version 4.0.

Where are you seeing this information? When managing a service? Is it simply a display issue, or do credits get added to the client account? It sounds like it's just a display issue, which is probably related to CORE-1773.

Support tickets identify the user from the 'from' address. The sender's response is sent to the 'reply_to' address, which identifies the support department.

There's no limit to making a payment for an invoice except when the invoice is already paid. What process of making a payment is not working correctly, exactly? Is this related to the link sent in an email, or a link in the dashboard, or..?

For the plugins, did you add the icons according to the documentation? Since these are plugin actions, they only update when the plugin is installed/upgraded.

Call Services::get using the API to fetch the service by it's ID. The service fields are available from the "fields" object attached to the service. e.g. <?php require_once "blesta_api.php"; $user = "username"; $key = "key"; $url = "https://yourdomain.com/installpath/api/"; $api = new BlestaApi($url, $user, $key); $response = $api->get("services", "get", array('service_id' => 1)); print_r($response->response()); print_r($response->errors()); ?>

Tags can be filtered as described in the H2o documentation. Unfortunately, the "date" filter for H2o only allows for you to format the date according to php's date function, which does not do timezone conversion. e.g. {ticket.date_added | date "M d, Y H:i:s A"} is "Feb 09, 2016 23:17:42 PM" UTC The timezone conversion is an additional step, so either a new tag would need to exist that displays the date in the appropriate timezone, or better yet, H2o would need to be extended to support a new filter for performing the timezone conversion. Only the tags shown on the Support Manager page documentation would be available. It's possible that a client may not be assigned to the ticket at all, if the ticket were emailed in, for instance. The plugin doesn't make additional queries to allow for these tags due to the performance hit it would incur. however, that may be a good feature request. The client, the contact that replied, the staff, and the department might be a good set of additional tags. The {ticket.code} is not necessarily a unique code, and it could be guessed. The {ticket_hash_code} does change per email, is unlikely to be guessed, and is used to determine the ticket the email is associated with.

Packages::add and PackageGroups::add are wrapped in a transaction at a higher level, in a controller. This is not ideal for the reasons I mentioned above, and is not a practice we would like to continue throughout the rest of the system. You can work around the transaction by using the Record component to insert values into the table directly.

I wouldn't consider this issue a bug. It just requires that you revise your approach to work around the fact that adding a package option group starts a new transaction. Removing the transaction from the model would entail all areas of the system that call this method should create a transaction instead. This widens the scope and complexity of managing transactions. Ideally, every model would impose its own transaction to be self-contained, and if you intend to chain multiple model methods together in a broader transaction, you would create a broader transaction, and the lower level model calls would use the broader transaction without imposing their own (nesting). That may be something we add in the future, but for now, I would suggest updating you plugin to record the package option groups itself without calling PackageOptionGroups::add.

Try this: SELECT `contacts`.*, `services`.`id` AS `service_id`, `services`.`date_renews`, `services`.`date_canceled`, `packages`.`id` AS `package_id`, `packages`.`name` AS `package_name` FROM `contacts` INNER JOIN `services` ON `services`.`client_id` = `contacts`.`client_id` INNER JOIN `package_pricing` ON `package_pricing`.`pricing_id` = `services`.`pricing_id` INNER JOIN `packages` ON `packages`.`id` = `package_pricing`.`package_id` WHERE `contacts`.`contact_type` = 'primary' GROUP BY `services`.`id` ORDER BY `contacts`.`last_name` DESC;

Do you only need the primary customer's name, address, etc., or do you need that information for every contact under that client (e.g. billing contacts)? Do you need a list of all services as well? What information about the package do you need? Just the package ID? The package name? Do you need to filter by a date range? I'm thinking you may want a list of every service for every client, so the export would contain every primary contact (multiple times for every service they have) along with the service/package information you want. Does that sound right?

"service.id" does not exist, so your query would lead to an error. The query you're using is also rather ambiguous. I'm unsure what data you're intending to retrieve. Even if you have the package ID, it would only be for one of the contact's services at random, which doesn't seem all that useful. It would be helpful to know the requirements for your report. SELECT `contacts`.`client_id`, `contacts`.`id` AS `contact_id`, `contacts`.`first_name`, `contacts`.`last_name`, `contacts`.`email`, `contacts`.`address1`, `contacts`.`city`, `contacts`.`zip`, `contacts`.`country`, `services`.`id`, `services`.`status`, `services`.`date_added`, `services`.`date_canceled`, COUNT(`services`.`id`) AS `number_of_services`, `package_pricing`.`package_id` FROM `contacts` INNER JOIN `services` ON `services`.`client_id` = `contacts`.`client_id` INNER JOIN `package_pricing` ON `package_pricing`.`pricing_id` = `services`.`pricing_id` GROUP BY `contacts`.`id` ORDER BY `contacts`.`client_id`, `contacts`.`id`