Tyson

The query only fetches contacts. If you wanted service information, you might select only the primary client contact, and list them multiple times, once for each service they have. However, the service name ("Label" in Blesta) is derived from one of the service fields determined by the module. That relationship could not be determined from a query since the module's chosen service name is not stored in the database. In other words, you could list all of the service fields for a service in a column, but you wouldn't know which one is used as the service name. If you know the name of the service field used as the service name for every module in your system, then you could add each one manually to the query to get just the service name.

If you sort by renew date by default, all one-time services will be at the top of the list since they don't have a renew date.

Yes, this is the option I was referring to in my previous post.

The ReCaptcha only works on the Standard order form templates, but not Wizard or AJAX. This is due to the fact the ReCaptcha cannot be loaded via AJAX. Blesta v4.0 has been updated to use ReCaptcha v2, which will require that you update your ReCaptcha settings in the Order plugin. Then, the captcha will display and work correctly in all order templates.

Thanks for the report. Your fix resolves the error, however, setting the coupon ID to null would remove the coupon (if there is one) from the service. Any price override would also be removed. This issue, and the others I just mentioned, is resolved in CORE-2181 for v4.0.

This is fixed in CORE-2179 for v4.0.

When you manage the module in Blesta, are there two module rows (servers) defined? Are they in the same group (if grouping is allowed for that module)? If so, you can manage the service and find a select option at the top of the Information page that allows you to switch module rows, which will update the module_row_id you are referring to.

Yes, that will update the setting for every client in the system. If you have multiple companies, or multiple client groups that support a non-email invoice delivery method, then you may want to further filter the query by company/client group. I've added the issue as CORE-2187.

Are you familiar with selecting service information? I'll assume so and let you work out that part. To narrow it down to a specific company, you will want to join with client groups, i.e. SELECT `client_groups`.`company_id`, contacts.first_name, contacts.last_name, contacts.email, contacts.country FROM contacts INNER JOIN `clients` ON `clients`.`id` = `contacts`.`client_id` INNER JOIN `client_groups` ON `client_groups`.`id` = `clients`.`client_group_id` ORDER BY `client_groups`.`company_id` ASC, contacts.country ASC;

I haven't heard of that happening before. Do you have any custom changes that might interfere with that behavior? Are you positive you had the "Create Invoice" radio option selected? A mis-click could select a different radio option to either append it to an existing invoice, or not invoice it at all. Can you duplicate this behavior consistently?

That is the v3.0 schema, which doesn't contain any of the upgrades since that point. We don't provide documentation on the database schema, but you can certainly install a trial and view its structure.

Could you be more specific? I'm not sure exactly what problem you're having.

This issue is fixed in v4.0.

Thanks for the report. This is fixed in CORE-2178 for v4.0.

This is fixed in CORE-2180 for v4.0.

This issue is fixed in v4.0.

The processor has been updated in CORE-1108 for v4.0. Only use the Google exchange rate processor after upgrading to v4.0.

This issue is fixed in v4.0

FYI, the issue described in this thread is assigned to CORE-2167.

A TIMESTAMP data type has limited range. Instead of a 9,000 year range of DATETIME (1000 through 9999), TIMESTAMP's have a range of 1970 through 2038, which is the signed 32-bit UNIX number of seconds since that start date. This can be problematic in the near future (if it's not already) for some instances, such as service renewal dates, which are stored in the future. Performing date conversions, or any other automated data manipulation, at the database level separates logic from the application. This can be useful in some cases, but has the trade-off of additional complexity in both implementation, testing, and understanding of the application. Additional complexity often leads to more bugs. If auto-conversion occurred for dates retrieved by a DBA that is manually fetching records, there is the question of what timezone he should be converting to. Will the DBA know that it may not be the database's timezone, server timezone, or even the PHP timezone that needs to be used? Will he know that the timezone is dependent upon the company that the data is associated with? The company timezone is stored as a setting, and would have to be referenced for the particular data set being fetched. If not careful, it's possible to fetch records for multiple companies of different timezones in the same query, in which case some dates may be incorrect (if the dates were auto-converted).

This is fixed for v4.0.

I added this as CORE-2177.

What file, line number, etc. is this code for? Is the bug an undefined property error, or simply that the phone number is not set? What are the requirements on passing the phone number? Do they expect international formatting?

I tested the auto-close feature and found that it is working correctly in my dev environment. The criteria for closing a ticket is pretty simple, but you should double-check these settings: The ticket belongs to a support department that has the setting Automatically Close Tickets set to a value other than "-- Never --". The ticket should have no replies to it since at least that many days. The last reply to the ticket should be by a staff member. The ticket should be set to a status that is neither "In Progress" nor "Closed". You can try running the following query to see if you get any results. It will tell you the ID of the tickets that should be closed. You may need to adjust the department ID and the date of the support replies to match your settings. SELECT `support_tickets`.`id` FROM `support_replies` INNER JOIN `support_tickets` ON `support_replies`.`ticket_id` = `support_tickets`.`id` WHERE `support_replies`.`id` IN ( SELECT MAX(`support_replies`.`id`) FROM `support_replies` WHERE `support_replies`.`ticket_id` = `support_tickets`.`id` AND `support_replies`.`type` = 'reply' ) AND `support_tickets`.`department_id` = 1 AND `support_tickets`.`status` != 'in_progress' AND `support_tickets`.`status` != 'closed' AND `support_replies`.`type` = 'reply' AND `support_replies`.`staff_id` IS NOT NULL AND `support_replies`.`date_added` <= '2016-04-16 00:00:00'; If you receive results from this query, but the cron still does not close the tickets, there may be an error validating the ticket on edit in SupportManagerTickets::edit. You may have to temporarily update that file to write all Input errors to a file so you can determine what may have failed to process.

It could be a bug, but i haven't tested it yet.