Tyson

What you have looks fine. It wouldn't affect the operation of other cron tasks. However, you should make a note of your file changes. Updating Blesta in the future can overwrite that file, and you would need to reapply your changes. The cron will catch up on billing anything that it had missed in the past. For instance, if the cron fails to run for a week, it will create that week's invoices the next time it is able to run successfully. This behavior is not shared with all other cron tasks. For example, if a payment reminder is set to be sent out 3 days before the invoice is due, and the cron does not run 3 days before that invoice is due, then that reminder will not be sent. Automatically adjusting renewal dates so they skip weekends is a much more complex task. This can potentially affect the system in unexpected ways, such as if you have a service that renews on a daily basis. For example, changing a daily service's renew date such that it next renews on Monday instead of Saturday would give two free days of service and no invoices would ever be generated for Saturday or Sunday. If you're mainly concerned with customers losing track of their invoices among spam and other email that they collected over the weekend, you might consider some alternatives, such as: Disabling the "Deliver Invoices" cron task on Friday and re-enabling it again on Monday. This can be done manually in the UI or automatically via a plugin. Continuing to send invoices on the weekend, but now also send them a reminder email on Monday containing a list of all currently unpaid invoices. This would be a plugin.

Invoices for service renewals are only generated once a day. If you want to prevent invoices for renewing services from being generated on weekends, you could update /app/controllers/cron.php and look for createRenewingServiceInvoices, which is the method you would want to update. Simply return an empty string from that method without doing anything if today is on a weekend.

Your example groups by the function DATE on `date_transaction`. Grouping on a date field is fine, but running it through the DATE function is redundant. I'm actually surprised that would work anyway considering DATE is not a supported aggregate function for the GROUP BY clause. Additionally, the field you select and group by, date_transaction, does not exist. I think you're referring to the date_added column? Yes, it is possible to convert it into a query using the Record component. BETWEEN is a clause, not an operator. You could still create a BETWEEN clause with the Record component, but based on your example, I think it would be simpler to instead create two conditionals in the WHERE clause to filter by date. Your query is very similar to the Transactions Received report under [billing] -> [Reports]. However, the query you posted is not valid because the `transactions` table contains no `date_transaction` column. What is the exact query you are running?

$this->Record->query(" SELECT date_transaction, IFNULL( SUM(amount), ? ) AS daily_sale FROM transactions WHERE date_transaction BETWEEN DATE_SUB(NOW(), INTERVAL ? DAY) and NOW() group by DATE(`date_transaction`) ", 0, 7); If you're using php, you might as well set specific dates to search between rather than using MySQL's functions like BETWEEN, DATE_SUB, and NOW. Also, I'm not sure why you are grouping on a column passed to the DATE function.

Well, if it looks correct once you've changed the precision, I'll go ahead and close this thread. The change I mentioned for updating the display of all formatted currency values would be apart of CORE-1092.

That might explain it. However, the addition of currency precision in v3.5.1 did not include updating every location in the system that might display formatted currency values. It probably should, but that would be a different task for another version.

Blesta uses the ISO-3166-1 standard for country codes and ISO-3166-2 for subdivisions. Hong Kong does not define any standard ISO-3166-2 subdivisions, which is why none are listed. I would suggest using my States & Countries plugin to update the entries to better suit your needs.

I'm not sure I follow. Do you have the currency set to the format "1.234" with the precision of "0"? The total should be formatted to zero decimal places. I suppose the unit price could show a decimal value if there is one, though. Is that what you're referring to?

Make sure php has the libxml extension and soap installed.

The "Pay Past Due" button simply checks the past due invoices to pay from the list of open invoices. Clients can still pay past due invoices whether they click that button or not. I'm curious why you would want to disable your gateway under that condition. In any case, you would probably want to update the client_pay controller to set a session variable to set whether that button was clicked, and then remove your gateway from the set of non-merchant gateways that are loaded up on the next page.

The only way I'm aware you might be able to do this without modifying the core is to use vQmod to create virtualized modifications to the core, e.g. to load your custom view rather than the default one.

You can update /app/controllers/client_main.php and change 'show_email' => true to 'show_email' => false

I'm not aware of an open task to tackle denoting required/optional fields on forms. This would have to be set manually, and with the complex rules available to each form field, some fields may be conditionally required. Form fields are included in a multitude of templates. If you know the URL, you can generally determine the template. e.g. the URL to /client/main/edit/ would load the template from /app/views/client/bootstrap/client_main_edit.pdt

As nelsa mentioned, go back to the page where you got the service information from your screenshot. Below that is an Actions heading with a drop-down selector. Choose "Change Renew Date".

Every client's currency should be in INR. You can uncheck the settings I listed above: Uncheck the setting Use Package Pricing for New Services Only Uncheck the setting Allow Client to Set Currency That will disable the client's ability to change their currency, so they will have to use INR. Unchecking the other setting will allow for currency conversions when package pricing is not defined in the client's default currency. Your domain packages should only define pricing in USD so that anyone that orders it will have invoices created using the exchange rate from USD to INR. Your order form should also only accept INR as the currency for payment. I think that should cover it.

Blesta will only take the customer to BitPay if it receives a valid response URL from BitPay that it can redirect them to, otherwise the page will reload. Check your logs under [Tools] -> [Gateways] -> (click the BitPay table row). What is the response from BitPay?

This issue will be fixed in v3.6.1 as apart of CORE-1871.

Do each of the affected services, and pricings, belong to the same package? If so, it'll probably be alright. Do any have package options? If so, you'll probably need to update those as well. There are a lot of rules in Blesta to ensure data integrity and validity between services and package pricing. The best way to avoid potential problems would be to update each service from the interface instead.

Package options are module independent, so you can create options for any purpose, be it for use by a module, multiple modules, or no modules at all. Modules do not have a way of pre-building, or making available, supported option values, like OS IDs retrieved via the API, when adding a package option in Blesta. The page to create/update package options only defines fields to be entered by a manual process, so users will need to have apriori knowledge of the available OS IDs so they can enter them themselves. As long as there is documentation available that describes your module's supported package options (like SolusVM), users should be able to do so without much trouble. However, you could create your own automated process for creating the module's package options by creating a plugin in Blesta.

Sounds like it's something we can look into in CORE-1872.

Each service has to reference valid pricing or it will not be able to generate invoices. I would not recommend updating the database directly as you may create more problems than you solve in attempting to do so. If you have multi-currency settings configured, you could do the following: Change your company's default currency to USD: [settings] -> [Currencies] Uncheck the setting Use Package Pricing for New Services Only Uncheck the setting Allow Client to Set Currency Change each client's default currency to USD Blesta will bill the client in their preferred currency (now USD) by converting your existing service prices (from INR to USD) via the exchange rate when generating invoices.

Thanks. CORE-1871

Nice catch. That's a very minor issue at worst, but nonetheless CORE-1870.

The DirectAdmin API does not appear to list any way to change an account password. Did they update their API to support that ability?

The Record component may not be connecting to the database, or because of some other error, perhaps because you're calling "fetchall" rather than "fetchAll". A plugin could be created that defines a model and method that performs the query, and then your module can call that plugin's model method to fetch the data. Using a plugin also allows you to better define the creation and removal of your database tables. You could also setup your module to not install itself if the associated plugin dependency is not installed first.