Jono

Ah, I think I may know the problem. I'll need to update the Blesta docs. When you log in to Paystack check out Settings > API Keys & Webhooks. In the Webhook URL field you should enter something like http://{yourblestadomain}/callback/gw/{company_id}/paystack.

Are you speaking of the email sent to staff members when a ticket is updated? That tag is not available in that email template. When editing an email template, the "Available Tags" section just above the text/html input lists all tags that are available to the template.

The first place to check is going to be the logs (which is the case for most problems people encounter in Blesta). Which non-merchant gateways, the primary suspect is usual the IPN callback that let's Blesta know that payment has been received. To confirm that an IPN callback you'll want to check the logs under Tools > Logs > Gateways. Search these logs for a paystack log with 'validate' label. If you find one, it may have a error that let's you know what the problem is. If there is no log that means that Blesta is not receiving the IPN callback. In this case it is likely a server configuration issue, such as a firewall not letting the request through.

This is controlled by the "Invoice Days Before Renewal" setting which can be edited under the client group or Billing/Payment > Invoice and Charge Options settings. This setting also determines the number of days before a service or recurring invoice renews to generate an invoice.

Hmm, well I have been unable to reproduce this. But if it does happen again you should be able to go into the admin interface and find the pending service, then click to manage it. Then empty whatever value is in the username field and activate it. That should generate a new username and provision fine.

Remove the pending service

Cool The fact that you are using the order form does narrow things down quick a bit since that means the service will only be provisioned by the cron (if an admin creates an active service through the admin interface then the service is immediately provisioned, the cron only provisions pending services with paid invoices). I wasn't able to immediately recreate the issue, it seems to properly recognize that the username is used and select a new one. That being said you clearly are getting an error so I'll keep poking around. One thought I had is that the username is determined when the order is placed, but the account is not created till the cron runs. Is it possible that the username is being taken in the time between the order being placed and the cron running (doesn't seem likely but I figured I'd ask)

Never assume that steps to duplicate are obvious. I can think of 4 different methods of provisioning a service in Blesta off the top of my head, and issues like these may affect only one method. Are you using the order form? Are you creating it through the admin interface? Is it being provisioned immediately or later by the cron? If you are creating it through the admin interface are you entering a username or leaving it empty so that the module will generate it automatically?

Check out custom reports under Billing > Reports. You can see the docs here: https://docs.blesta.com/display/user/Generating+Reports. The following query would give you something like what you want if you have a 'cutoff' field in your report: SELECT `contacts`.* FROM `clients` LEFT JOIN `log_users` ON `log_users`.`user_id` = `clients`.`user_id` AND `log_users`.`date_updated` > :cutoff INNER JOIN `contacts` ON `contacts`.`client_id` = `clients`.`id` AND `contacts`.`contact_type` = 'primary' WHERE `log_users`.`id` IS NULL

Another option is to use the field in the same way that VPS.net does, watching for a field to change and then submitting the form via JS with this field set to 'true'.

Not a perfect solution, but a while ago we added the option to include a refresh_fields field which would allow you to submit and refresh the fields without receiving errors. Could look something like this: $label = $module_fields->label('Refresh Fields', 'refresh_fields'); $refresh_fields = $module_fields->fieldCheckbox( 'refresh_fields', 'true', (isset($vars->refresh_fields) ? $vars->refresh_fields : 'false') == 'true', ['id' => 'refresh_fields'] ); $label->attach($refresh_fields); $module_fields->setField($label);

Here is the doc page for adding companies https://docs.blesta.com/display/user/Creating+Companies

This is a bug in 4.7.0. See CORE-3275. We hope to release 4.7.1 early this week.

Thanks for the feedback and the fix! Presumably the +1 is meant to be included. This looks like an issue with the order of operations. The dot operator is executed before the plus operator so that the expression is nsi + 1 (where i is the value of $i), which causes the error. I would suggest wrapping $i+1 in parens instead ($i+1). I've create CORE-3282 to update this.

Your looking for the language files under plugins/order/language. Language files are named after the controller or model they are used in. Some appear in the main language directory, while language that is specific the modules, gateways, and plugins will appear under their specific directories: plugins/your_plugin/language, components/modules/your_module/language, and components/gateways/merchant//your_gateway/language. In the view files you will see something like $this->_('Order.main.domain'); And in the language file you will see a matching row like: $lang['Order.main.domain'] = 'Domain';

Chances are that it is on a non-active service and was overlooked because of it. The pricing id can be found be going to the package edit page, right clicking on the term test box and opening your browsers inspector. Right above the term field you will see a hidden field called pricing_id. You can take this pricing_id and search your "services" table for it. That should be the one you are looking for.

It has come to our attention that under some circumstances in Blesta 4.7.0 (e.g. when a client is adding an addon service through the client interface) users can receive a fatal error "Undefined property: Services::$Clients on line 5159 in path_to_your_blesta\app\models\services.php". This is a bug that will be resolved in 4.7.1 (CORE-3271). You can fix this issue by changing app/models/services.php lines 5112-5114 from if (!isset($this->Packages)) { Loader::loadModels($this, ['Packages', 'Clients', 'ClientGroups']); } to Loader::loadModels($this, ['Packages', 'Clients', 'ClientGroups']) Or you can override app/modelsservices.php with the attached services.php file services.php

Probably want to create a new thread for that or post in the discord channel.

Pretty sure the problem with the coupon is that it is only set for the NAD currency

Hmm, you can update line 256-260 of gocardless.php from: if ($this->ifSet($_GET['pay_type'], $_POST['pay_type']) == 'subscribe') { $pay_type = 'subscribe'; } elseif ($this->ifSet($_GET['pay_type'], $_POST['pay_type']) == 'onetime') { $pay_type = 'onetime'; } To: if ($this->ifSet($_GET['pay_type'], $this->ifSet($_POST['pay_type'])) == 'subscribe') { $pay_type = 'subscribe'; } elseif ($this->ifSet($_GET['pay_type'], $this->ifSet($_POST['pay_type'])) == 'onetime') { $pay_type = 'onetime'; } I'll create an issue on the GitHub repository for this

Would you mind updating components/modules/tcadmin/api/tcadminapi.php line 68 from: if ($host_name_output != false) { to if ($host_name_output != "<?xml version='1.0'?><document></document>") { The visit the page again and post the log. It looks like the module has an bug with logging errors properly, I've created a task on github to fix this.

The docs should probably be more clear. It says that vars "may include following". The client_id is not guaranteed to exist (the validation rule uses an if_set on edit), so if no client_id was submitted to Services::edit() then none will be available to the event. That being said, you can always fall back in the old_service client ID if one does not exist in vars.

Hi there, A couple quick questions. What version of Blesta and the TCAdmin module are you using? Have you checked the module logs under Tools > Logs > Module to look for errors? If there are any errors in those logs can you share them here?

Are you saying that you want to view the client profile in their preferred language? Or you just want to see what it is? The first seems a bit odd, because you might not even understand whatever language they chose. Maybe we could have a language selector but default it to the admin's language. The second can be accomplished by editing the client through the admin or client interface.