Jono

Having a bit of trouble recreating the error. Would you mind sending me a personal message with some test data?

@WinsomeHost This looks like an issue we recently resolved. It is possible that downloading the newest version of the sslstore module here https://github.com/blesta/module-thesslstore will resolve the issue.

Awesome, thanks! I should be able to resolve this soon.

Does it create the one with the correct info as well?

@Usman Nasir Hi there, looking into this issue. The multiple account creations is intentional as it is used to check the availability of a username. If there is a better way to do this please advise us. @Lampard The account/website created to test the availability of the username should be deleted right after. Are you saying that ONLY the account with incorrect info is created? What do you mean when you say "Password doesn't work..."? Do you mean that clicking the service login link does not work?

I don't understand your question. Are you wanting to create a new department at the time a client opens a ticket?

Try again, then look at your module logs under Tools >> Logs. There should be a cPanel log for listpkgs and I imagine the output log will show you some kind of error returned by cPanel.

Turns out it is an issue with permission for fetching the modal. To fix you can alter app/client_controller.php starting at line 17 from // Allow states to be fetched without login if ($class_name == 'ClientMain' && (in_array(strtolower($this->action), ['getstates', 'setlanguage']))) { return; } to // Allow states and dialog to be fetched without login if ($class_name == 'ClientMain' && (in_array(strtolower($this->action), ['getstates', 'setlanguage'])) || $class_name == 'ClientDialog' ) { return; } This fix will be included in v4.4. See CORE-2850

Can't be done without modifying the files for the support manager plugin. In {blesta_dir}/plugins/support_manager/models/support_manager_tickets.php you can change lines 1230 - 1239 from public function getPriorities() { return [ 'emergency' => $this->_('SupportManagerTickets.priority.emergency'), 'critical' => $this->_('SupportManagerTickets.priority.critical'), 'high' => $this->_('SupportManagerTickets.priority.high'), 'medium' => $this->_('SupportManagerTickets.priority.medium'), 'low' => $this->_('SupportManagerTickets.priority.low') ]; } to public function getPriorities() { return [ 'high' => $this->_('SupportManagerTickets.priority.high'), 'medium' => $this->_('SupportManagerTickets.priority.medium'), 'low' => $this->_('SupportManagerTickets.priority.low') ]; }

The user is given an option to either use their email or to specify their username. Are you looking to remove the option of using their email?

Requires a little JS <?php $this->Javascript->setInline(" $(document).ready(function() { $('#content').ckeditor(function() {}, {language: '" . substr(Configure::get('Blesta.language'), 0, 2) . "'}); }); "); ?>

Just a note, CORE-2600 is scheduled to be in the 4.4.0 release.

It would be in the preaction. The order_controller.php and order_form_controller.php files from the order plugin I think may have an example of something like this if I'm understanding rightly what you want to do.

You are saying that the cron ran and generated an invoice for a pending service? Do you mean a suspended service? That can be configured to happen. But looking at the code I don't see how a pending service could be invoiced.

My pleasure, sorry for the inconvenience.

Took another look at the code and it appears that this is a problem that applies exclusively to ajax type order forms. I've created CORE-2702 in order to fix this, but for now you would have to switch to a standard or wizard type order form for the credit option to be displayed.

This should be included in the default behavior. When a client has credit a check box labeled 'Apply Credit ([credit_amount] Available)' should appear under the dropdown labeled 'New Payment Details'. If you have no payment methods available for that order form then the 'Apply Credit' option will not appear. Again, it will only appear if the client actually has credit.

Haha yep, I definitely read it as credit card. Let me take a look and I'll give a clear answer to your actual question X)

Not sure you could do that if you wanted to keep the client and simply make them inactive. A client without a contact seems problematic. If you are looking for relations on the client_id then there are some others. module_client_meta - Blesta Core client_notes - Blesta Core client_packages - Blesta Core client_settings - Blesta Core client_values - Blesta Core reseller_pricing_clients - Reseller Pricing support_tickets - Support Manager You should also be concerned with tables related on the contact_id accounts_cc, accounts_ach - Blesta Core contact_numbers - Blesta Core contact_permissions - Blesta Core log_contacts - Blesta Core support_replies - Support Manager download_logs - Download Manager mass_mailer_tasks - Mass Mailer I think that covers everything you missed.

The answer to you first question is no, we do not currently integrate with paysafecard. As to how much effort it would be to do that, it really depends on how good the API is and what functionality you want to support. Usually just receiving payments is not terribly hard to implement. To get an idea of what is involved you can look at https://docs.blesta.com/display/dev/Payment+Gateways. Additionally you can look at the existing gateways either on our github or in the file system under components components/gateways/. If you want to get a developer to produce this for you or give you a quote, you can find a list here. Each of them are here on the forums and you could send them a PM. Your second question has a bit easier and more satisfactory of an answer. First, make sure you have a merchant gateway installed (e.g. authorize.net, stripe, etc.). Then when you add an order form at admin/plugin/order/admin_forms/add/ check to enable the merchant gateway and currency you want. After that you customers should be presented with the option to pay with credit card on checkout .

Are you referring to the module logs? These are stored in the database in the 'log_modules' table and can be viewed through the interface at admin/tools/logs/module/.

Are these settings being overwritten by the client group settings?

Tools >> Logs >> User Logins. Hope that helps

For step 4, you are correct in saying that Blesta does not support redirects for merchant gateways. Is there a reason you are not implementing this as a non-merchant gateway? Does the API not support that? Unfortunately non-merchant would allow the client to choose their payment method each time they are invoiced, so you could not do step 5. For step 5, well each currency is only allowed one merchant gateway so that should be happening automatically. Are you asking how to enable auto-debiting?

Probably the most straight forward solution would be to change the status of the ticket when you reply. Likely you would change it to "awaiting reply". Then after the client replies it will automatically be transitioned back to the "open" status.