Tyson

The screenshot shows the user interface, but not your request sent via the API. If you're making an HTTP POST request using the API SDK you downloaded, you would do so similar to the examples shown in the API SDK readme.

What request data are you sending?

Have you read the documentation regarding the API? Have you tried to use the API SDK to help simplify making API calls? Have you looked at the source documention regarding the creation of clients? You can make a call to Clients::create to create a user account, client account, and contact in Blesta by passing all of the necessary information from data you retrieve from your current customer list.

I like the idea of making more data available, but this is something we'll need to discuss internally first.

If you were to do it that way, by changing the service's invoice such that the system does not consider it when renewing/suspending the service, then what you described can work. From a technical stand-point, you are removing the service relation from the invoice line item. You can accomplish similar behavior directly from the database by setting a NULL value for the `invoice_lines`.`service_id` column for that particular invoice. You would want to ensure that none of the invoice line items are associated with the service ID anymore.

What process are you going through to move services between clients?

I'm not sure changing the cron time will have much of an effect because of the stored datetime stamps. Since you're UTC+1, you can try running cron tasks at midnight UTC or later, i.e. "01:00:00" UTC+1. Since the dates are stored in the database with the time "00:00:00", and your timezone is UTC+1, those datetime stamps represent the day before, at UTC time 23:00:00. I think this is the issue because the service falls on a different calendar day UTC (off by an hour). It's also why changing your timezone in Blesta to UTC causes the dates to be consistent.

Thanks. I took a look and it appears to be a bug with the way the packages are listed with respect to their status and package group. We'll fix this apart of CORE-2164.

That's interesting. Are any of those packages add-ons? What HTML set for the service drop-down list?

The invoice should belong to the same client as the service. If you're moving services between clients, then the new client should pay for it, or have record of it's payment.

What are the service dates for the service related to that invoice: date added, date renews, date last renewed? Your bill date looks correct because the cron ran at midnight on April 3, which indeed matches 2016-04-02 23:00:12 UTC+1. If Blesta retrieved all services to renew 7 days from the cron run time (2016-04-02 23:00:12 UTC+1), it would fetch all services whose renew date is on or before 2016-04-09 22:59:59 UTC+1. Since the invoice due date is set to the service renew date upon creation, the service renew date must be 2016-04-09 00:00:00 UTC+1. I suspect that this service should have been renewed a day earlier, but was not for some reason. Was the cron run the day before for this task?

Besides disabling the cron task to Process Service Renewals, or bumping the service's renew date before-hand, there is no option to toggle a service to skip a renewal.

The fact you have no logs seems to indicate that PayPal didn't respond, or the response was not interpreted by Blesta. The gateway tells PayPal to respond to the callback URL, e.g., https://yourdomain.com/callback/gw/1/paypal_payments_standard/?client_id=123 You might try going to that URL in your browser after you set your domain and correct path to Blesta. If it's correct, you will be redirected. You should then have a log under [Tools] -> [Logs] -> (Gateways tab) showing that Blesta tried to validate the information.

If you create a plugin that updates invoices from the Invoices.add event, then yes, it will also affect automatically-generated invoices.

Did you generate an invoice for the service renewal when you manually renewed it? Or do you want an invoice to be created for renewal even though you already renewed it? Normally, I would say that you can bump the service renew date to the next date it should renew, since you already renewed it manually. However, bumping the renew date changes when the next invoice is generated for the service. If you renew the service manually and want Blesta to not do it, but you still want it to be billed, you can bump the service renew date and manually create an invoice. Invoice line items cannot yet be set to a service manually, so your manually-created invoice would not suspend the service if they failed to pay it.

I'm not sure why that is either, but I've added CORE-2154 to address it. I see staff listed under gateway logs, though. No staff entry would indicate it was performed by the system.

Services are suspended if they are more than one day (>24 hours) in the past. So in your example, the 1 minute difference would not qualify it as suspendable even if that minute separated two calendar days. That behavior might be a good feature request, though.

What is the `invoices`.`date_billed` for that invoice in the database? And what is your timezone set to? v3 of Blesta stores all dates in UTC, so the issue may be that your old dates from v2 were not offset by your timezone.

We should be able to fix the fatal error you encountered in CORE-2153. However, Stripe thinks you have invalid authentication credentials. You should double-check that your API key is correct, e.g., doesn't contain any unnecessary spaces, etc.

Icons can be added into the client SUB-navigation, but not the primary navigation. See the docs. e.g.: array( 'action'=>"nav_primary_client", 'uri'=>"plugin/download_manager/client_main/", 'name'=>Language::_("DownloadManagerPlugin.client_main", true), 'secondary' => array( 'plugin/download_manager/client_main/' => array( 'name'=>Language::_("DownloadManagerPlugin.client_main", true), 'icon'=>"fa fa-download" ) ) )

If a task stalled, it will attempt again in 6 hours. If the issue is caused by an error (e.g. some run-time error), you could remove the log for the offending task and run the cron again manually with error reporting on so you can determine the error and resolve it before the task runs next time. Adding the ability to run cron tasks outside of their scheduled time/interval to run can be dangerous, though, if it was already run today or is still running. You could end up with the same task being performed twice (or more) on identical data. It may be better, especially for your case, to make it easier to restart a stalled task. There have been some suggestions before, including adding a page that lists failed tasks, why they've failed (if available), and an option to restart them.

So you would like there to be an option when a service is manually created/activated by an admin for the module row to be specifically selected? Such as an option to Choose Module Row with values of "Use From Package" or choose one of the module rows from a list?

A plugin could probably be created to update the invoice due date on creation using the Invoices.add event, if you think that might work for you.

A service is unsuspended after an invoice is generated for it? If there are no past due invoices for it, then it could be unsuspended. Blesta does look at the `log_services` table when unsuspending a service, and the service would need to be in that table. Perhaps that is an issue for you from the import.

The task, CORE-1061, that Paul mentioned hasn't been scheduled for a version yet.