Tyson

Sounds like you may need to tie into the GatewayPayments component where a payment is deemed successful, determine whether any invoices were directly paid, then determine the services on those invoices, then make a post request to your URL.

The cron sends invoices automatically via Cron::deliverInvoices.

If, for example, the service gets canceled it cannot be reactivated. So can a client order a package more than once in certain scenarios, such as if it is no longer active or if it is canceled?

This sounds normal. Splitting a ticket does not also change it's ticket status. Since it is currently open, it would stay open after it was split. I think you received that error because you changed the ticket status to the same status that it currently was. Because the status is not changing, the ticket does not need to be updated, and does not log any details about the status change, hence the error.

See CORE-1803. Since you and your clients find "Invoice Number" confusing for pro forma invoices, do you also suggest separating pro forma invoices and regular invoices from the list of invoices in the client/admin UI shown on the client profile?

Try this $vars = array(); $view_path = $this->view->view_path; $this->view->setDefaultView(APPDIR); echo $this->partial("admin_login", $vars, "admin" . DS . "default"); $this->view->setDefaultView($view_path);

How about: $vars = array(); $this->view->setDefaultView(APPDIR); echo $this->partial("admin_login", $vars, "admin" . DS . "default");

See this thread. It looks like you are setting a message in your controller without noting that it should be displayed in Blesta's default message template. Because of this, it expects that you have created your own message template in your plugin, which does not exist. Look at your calls to setMessage and flashMessage and ensure you are setting each parameter, specifically false to the last one ($in_current_view).

The user ID and client ID reference different tables in the database and represent different records. While it's possible the user ID and client ID can be the same for some users, it is not reliable to assume this to be the case. You should reference the correct ID for what you're trying to do. user ID = user login information client ID = client information Every client has a user, but not every user is a client.

Whose first and last name? We can add the name of the person that last replied to the ticket, like the Staff Ticket Assigned template supports. However, you will need to include logic to differentiate whether the ticket was emailed in or not, as there may not be a first or last name. Closing a ticket can be done at the same time as assigning a response. Would you prefer they be sent two emails? I think you can use the Ticket Updated email template to include logic to determine whether the ticket has been closed, and set additional information, e.g. {% if ticket.status = 'closed' %} This ticket has been closed. {% else %} This ticket has been updated. {% endif %}

Thanks. CORE-1799.

Make sure your Root Web Directory setting is set correctly. The cron may not be able to generate URLs appropriately in emails it sends via CLI if this path is invalid.

Log into a client account (under [Clients] -> (click one to view their profile) -> (click "Login as Client" under Account Actions) -> (click "Pay" next to one of their invoices). This is the payment page they would see. Depending on how you take payment (e.g. gateways supported), they should see what Licensecart has shown in his screenshot.

The removal of tax from a 100% discount is not currently possible, as you've encountered. A future release will update this when the remainder of the system is converted over to the new item pricing calculations. In the meantime, manual intervention is required to resolve the issue. You can disable tax from every line item of the invoice, or as Licensecart said, void the invoice altogether.

Make sure this path is correct. The cron may not set the correct paths in email template URLs via CLI mode if this value is incorrect. This is almost certainly the cause of the problem you are experiencing. The "sent status" that appears next to invoices is only updated when the invoice is sent automatically. If you have the cron enabled to send invoices, as it appears you do, then the invoice will be sent the next time the cron runs. There is no need to send it manually as well unless for some other reason. Invoices will be delivered based on either the Invoice Delivery (Unpaid) or Invoice Delivery (Paid) templates depending on whether the invoice has been paid. The payment URL is generated automatically and replaces the {invoice.payment_url} tag from the template when the invoice is sent.

This is the user ID. The client ID would be available with: $vars->client_id However, the content of $vars changes based on post data. For example, if there was an error on the page, the page would be shown again and $vars would not contain the client ID any longer.

H2o is used in locations where tag replacement can occur, but obviously this does not occur for every input field. Another possible work-around to the JS problem is to update the parser options Blesta defines for H2o in the config by changing the expected syntax characters (i.e. { and }) to something else, and subsequently updating each place that tag is used (e.g. email templates, portal, etc.) in Blesta.

Could you provide an example test case where this occurs?

Someone asked me about this the other day. Here is my response: The Portal plugin is not intended to support JavaScript from its input in the UI. JavaScript conflicts with the H2o parser for tag replacement because it contains braces (i.e. { and }). If you would like to set that JavaScript to the portal, it would be better to set it in the template that displays the portal instead. You can find that template at /plugins/cms/views/default/main.pdt. Since it's a core change, you should probably make a note of the fact a core file has been changed. You can use vQmod to perform 'virtual' changes to the core without making real core file modifications. However, if the file gets updated in the future such that your custom vQmod change no longer applies, you would need to re-add your custom change with a new vQmod addition.

Via the API you would have to fetch the client and then fetch his services, and manually sort out whether they have an active SolusVM service and what the main IP may be. If you simply need a list to reference, a CSV report may be useful. Create a custom report under [billing] -> [Reports] with a query for what you want to fetch, e.g. SELECT REPLACE(`clients`.`id_format`, '{num}', `clients`.`id_value`) AS `id_code`, `service_fields`.`value` AS `main_ip` FROM `clients` INNER JOIN `services` ON `services`.`client_id` = `clients`.`id` INNER JOIN `service_fields` ON `service_fields`.`service_id` = `services`.`id` WHERE `services`.`status` = 'active' AND `service_fields`.`key` = 'solusvm_main_ip_address' GROUP BY `services`.`id`, `clients`.`id` ORDER BY `id_code` ASC;

I wouldn't mind including a column for the client's name (or email, if unknown). e.g. Assigned To John Doe email@abc_xyz.com

The ticket listing page probably doesn't make the client's name available for each ticket. You would need to update the controller to fetch each client yourself before they would be available to the template.

If the ticket is emailed in, there may not be a client. We can display the email address that created the ticket instead, though, like the last reply currently does.

You mentioned that while using the callback URL a transaction was created. Then you mention that the transaction is not stored in the database. Can you elaborate? A transaction cannot both exist and not exist at the same time (unless it's a Schrödinger's transaction?). When Blesta receives a response at the callback URL, it will process the transaction assuming your gateway's validate() method returns the expected information from which to create one. The client will then be redirected to the payment received page. No transaction information is currently available here, so you wouldn't be able to show anything more informational to the client. The problem with this is it can lead to duplicate transactions for the same payment. The return URL doesn't need to store transaction information, as the gateway should be using the callback URL instead, which does this already and then redirects the customer to the return URL. Blesta already accepts that some gateways do not have a notification system, which is why the callback URL should be used. This may be a good addition, yes. Showing the transaction ID would be apart of showing the result of the transaction as you mentioned above. There are almost always multiple solutions. In this case, it would not be recommended to have both methods record transactions as they are intended for different work flows, and as mentioned, you could end up with duplicate transactions. Instead, passing the transaction that was created in the callback to the return URL would make it available for display to the customer.

I don't experience it with Safari version 5.1.7. It looks to be a bug with Safari >= version 6 in how it interprets CSS fixed positioning. I would recommend using one of the other browsers until they come up with a fix. Or, you could try to implement some kind of work around in Blesta to get it to appear.