Tyson

We need more info as described in How to Report a Bug. Check your module log for the input/output of an unsuspension request and look for errors.

Client groups have their own settings, so a client in multiple groups (if it were possible) would have 2 sets of settings with potentially different values. For example, invoice days before renewal might be 2 days in one group, but 10 days in another. When should Blesta invoice a renewing service? That's just one example, but there's plenty more going on that would inhibit a many-to-many relationship like that.

Make sure hashes are not explicitly disabled in PHP with --disable-hash.

The invoice_delivery table contains the list, and the date_sent updates to the current time when you mark an invoice printed.

Clients::edit() does not accept a 'first_name' vars parameter. It sounds like you want Contacts::edit(). e.g.: $params = array('contact_id' => 1, 'vars' => array('first_name' => "Piyushh")); $api->put("contacts", "edit", $params);

The original post has been updated with cPanel Extended v1.1.0, for use with v3.1.0 of Blesta. At the time of this writing, v3.1.0 of Blesta has not been released.

Depending on the interval you have set for that task on the Company Automation page, it may have already run via cron. You can check the timestamp next to the task on the Company Automation page for "Download Tickets" to see if it has ran in the last few minutes. Assuming you have a 5 minute interval on that task, if the timestamp next to the task is not within the last 5 minutes, it did not complete. Tasks can't be forced to run outside of their scheduled interval, so running the cron manually may not run the task. Adding to what I mentioned in the previous thread I linked, you would need to set a `log_cron`.`end_date` in the database that is more than 5 minutes from now, and then immediately run the cron manually through the interface. If the task fails to run again due to some error, you'll see that error in the interface when running the cron manually.

Tax can be added on a per line-item basis, so some line items may or may not have tax applied for a given invoice, and it wouldn't be known which item is taxed without the line item cost including tax. Nonetheless, you can change this by updating the file that generates the PDF. This is a core file change. You didn't mention which version of Blesta you're running, so I'll assume v3.1.0-b2. Update /components/invoice_templates/default_invoice/default_invoice_pdf.php if you're using the default invoice template (as opposed to the quickbooks one): 'price'=>$this->CurrencyFormat->format($this->invoice->line_items[$i]->total, $this->invoice->currency, self::$standard_num_options), to 'price'=>$this->CurrencyFormat->format($this->invoice->line_items[$i]->subtotal, $this->invoice->currency, self::$standard_num_options),

You would need to compare the last run time versus the time the task was supposed to run from the Company Automation page. In v3.1, that page will highlight tasks that have failed to complete, and give you an option to reset it. But until you're on that version, this thread might help. When you determine which task has failed, you can clear it from the database and try to run the cron manually through the interface. If there are any fatal errors, they should be listed there.

Correct. If a service was not added or canceled using the module, then the count wouldn't be updated.

DirectAdmin updates number of accounts using a best-effort policy when a service is added or canceled in Blesta.

What's different about these invoices? Do you have any recurring invoices/services that generated these invoices? How often does it happen? If you can't reproduce it, then we can't determine if it's a bug, nor how to fix it if it is. We need as much info from How to Report a Bug as possible.

Sounds like the issue is your value "yes|Yes". Per the documentation, the value should be set to "yes:Yes". If you had more than one checkbox, you would use the pipe character (|) as the delimeter, e.g. "yes:Yes|no:No".

Do you continue to experience the issue if you create a new package and select the server explicitly?

You may want to create a bug report for that, with steps to duplicate.

If you're referring to the admin interface, I think you would want the /app/views/default/admin_clients_view.pdt template, however, I don't think custom fields are available to that template. You would need to update the AdminClients controller to make them available. Of course, making changes to core Blesta files will require you to back up the files you modified and merge your changes with any patches or updates to Blesta that you download in the future.

Supporting formatted custom client date fields could likely be in the core, I speculate, but having an email sent based on the value of certain custom fields is better suited to a plugin.

CORE-979 for v3.1.0 of Blesta fixes this by updating the module options after changing the group.

What most/all of the modules do is use the first module row if one cannot be found. So what I think happened is that you first selected the DirectAdmin module, it loaded up with the Server Group set to "Any", and chose the first module row it could find. Then you changed the group to one that had no servers in it, and none of the fields updated. Not until you tried to save the update did you notice the fields were blank because that server group has no servers. I created CORE-979 to resolve this.

Ah. I thought you were referring to the database schema needing a MySQL date or datetime type. Sending emails based on custom fields may be better suited to a custom plugin.

The cPanel Extended module will most-likely never be released officially with Blesta. We don't intend to introduce new features for this module, and consider it rather low-priority on the fix list, since it is a 3rd-party module. Instead, we maintain our own cPanel module, which in the future, will contain more of the features currently available in this cPanel Extended module.

The problem is that the module row (server) is unknown, and passes a NULL value to Module->log(). Did the service actually get provisioned in cPanel? I suspect not because the server's host name is unknown. You should double-check your module settings, and the settings set on the package you're attempting to provision.

Closing as not a bug.

Paper refers to how to deliver the invoice, i.e., you print them out on paper under the Print Queue and deliver them to the customer by mail, or by some other method. Email delivery is configured under [settings] -> [Company] -> [Emails] -> , and are sent when certain criteria are met, e.g., to remind the customer that an invoice is due soon.

Is there a particular reason you need the database to use a date type rather than the current text type?