Tyson

This issue was resolved in CORE-1602 for v3.4.3.

This is resolved for v3.5.0 in CORE-1618. Existing group ordering will be kept, and any new packages will continue their current behavior of being at the top of the list until re-ordered.

Each gateway has its own specific requirements, so we mostly include information on integrating it into Blesta by describing the required file structure and providing an example gateway. There probably should be documentation on required/optional methods, similar to modules. In the meantime, you can determine the required methods by looking at the Gateway and NonmerchantGateway classes included in Blesta under /components/gateways/lib/. Each abstract public function must be implemented in your gateway. These include: setCurrency getSettings editSettings encryptableFields setMeta validate success You must also set a name, version, author, and list of supported currencies for the gateway. There are methods you can write for this, but you should use a config file instead. You should also write the buildProcess method, as this creates the payment page that customers will go to just before they continue offsite. Optionally, your gateway may support voiding or refunding payments, which you can implement via void and refund respectively. This information is handled via getSettings, editSettings, setMeta, and encryptableFields in the gateway, and in a template view settings.pdt where you set those fields. This would be set in buildProcess and in the template view you create for that page, process.pdt. This would be handled via validate and success in the gateway. You would probably include this as a helper method in your gateway.

The error you encounter with some language terms should be resolved once the translator is updated to include the next version (v3.5.0) after its public release.

The cron log you included shows the service could not be processed with the module. Looks like it didn't cause the cron to stall at least, which is a plus. however, you should check the module logs under [Logs] -> [Module] to see if there is any more detailed error on why it failed to provision the service. Firewall settings/logs should be available to the server admin. Tutorials and documentation would be based on the firewall, OS, etc., and I don't know enough about your system to give more insight. But since your cron didn't stall this time, there may be something more descriptive in the Module Log to check first.

There are two URLs a gateway typically needs to use. First, the payment callback should be sent to: Configure::get("Blesta.gw_callback_url") . Configure::get("Blesta.company_id") . "/yourgateway/". $client_id Second, the client should be redirected to: domain.com/blesta/client/pay/received/yourgateway/client-id/ ...which should be provided to the YourGateway::bulidProcess() method in $options['return_url']. If the gateway only supports one of these, use the callback URL.

Have you taken a look at the Payment Gateway documentation for Non-merchant Gateways? The SDK provides a sample non-merchant gateway to help get started with one yourself. If you need to set javascript on the payment page, you can do so in YourGateway::buildProcess(), which is where you render the view that includes the pay button a client will click to be taken offsite for payment.

The cron task for auto debit is only run once a day at the time specified. If it already ran today, it would not run again until tomorrow, even if you changed the time that it is set to run at. It probably was not auto debited because the task already ran today and the invoice was created after the cron ran to auto debit invoices today. I suspect the invoice would be auto debited the next day if it was not paid manually before then.

Take a look at this thread. You could update a few files in Blesta's core to address this issue (as mentioned in that other thread), but we haven't released better support for international addressing as discussed here yet.

Click on that text and the details should appear below it. The documentor isn't formatting the fields onto new lines for some reason, so you may want to do that yourself for better readability: Clients::create( array $vars ) Vars An array of client info including: - username The username for this user. Must be unique across all companies for this installation. - new_password The password for this user - confirm_password The password for this user - client_group_id The client group this user belongs to - status The status of this client ('active', 'inactive', 'fraud') (optional, default active) - first_name The first name of this contact - last_name The last name of this contact - title The business title for this contact (optional) - company The company/organization this contact belongs to (optional) - email This contact's email address - address1 This contact's address (optional) - address2 This contact's address line two (optional) - city This contact's city (optional) - state The 3-character ISO 3166-2 subdivision code, requires country (optional) - zip The zip/postal code for this contact (optional) - country The 3-character ISO 3166-1 country code, required if state is given (optional) - numbers An array of number data including (optional): - number The phone number to add - type The type of phone number 'phone', 'fax' (optional, default 'phone') - location The location of this phone line 'home', 'work', 'mobile' (optional, default 'home') - custom An array of custom fields in key/value format where each key is the custom field ID and each value is the value - settings An array of client settings including: - default_currency - language - username_type - tax_id - tax_exempt - send_registration_email 'true' to send client welcome email (default), 'false' otherwise

Since there is no error displayed, and the account was created in WHM, I suspect there is a communication problem between cPanel and the server Blesta is installed on. It doesn't appear that Blesta is receiving a response from cPanel that indicates the WHM account was actually created. Have you checked your firewall settings to see if any incoming requests are being blocked?

Config options (belonging to a service) would show their service number as well. You would want to know which service a config option belonged to, no? Sometimes, especially with prorated upgrades/downgrades, an invoice may only contain a prorated config option line item.

The SolusVM module will allow you to set your own configurable option for templates, so you could set your own name and order. But it probably would be best to sort the templates alphabetically if you choose not to use config options.

Yes, javascript is integral to the use of the client interface. It would not be possible to get the client interface to work for users that disabled javascript without limiting, changing, and/or removing functionality from the interface in several areas.

You would need to create users and contacts based on those clients as well, so it is a little more complex than importing data into a table. If you are familiar with PHP, you may want to take a look at writing a script to utilize the API to create clients. If you do it this way, you can be sure that there is no missing or invalid data, as Blesta will perform error checking during the import. Take a look at the API and creating a client.

Have you added any third-party extensions to Blesta? Short of some custom code or manual intervention that might have affected it, I'm not sure why it was suspended before the renew date. If you can, try to keep an eye on it to see if it happens again to any other services.

I'm not sure why you included a diff of some code from the Invoices model, but if you want to delete an invoice line item, you should pass in the invoice line item ID, an empty amount, and an empty description.

While you can create your own payment gateway and integrate it into Blesta, it sounds like you want to take it a step further by changing the way that payment methods/gateways are displayed. A client can pay through the client interface, or on the last step of an order, so it may be necessary to update those two separate places to add in custom changes. You could create a set of templates for your own view (not the default view), and make any custom changes (html, javascript, etc.) in them without affecting core files. If your changes are simple, it might be possible to employ vQmod instead, which will add in your custom changes without affecting core files, but it is rather limited. It's often difficult to make custom changes without affecting core files, so I suppose it depends on how custom you'd like to make these updates. The problem with any custom changes--whether they directly affect core files or not--is that they likely depend on data or structures in Blesta that may change in future updates of the software. So maintenance between versions would still be necessary. I may need more specifics, but it sounds like you could write a plugin in Blesta to accomplish this, by creating a cron task that auto-fetches pricing information over the reseller API, and updates specific packages in Blesta to set that pricing. The cart in Blesta is apart of the Order plugin. It should be possible (although I've never tried) to mimic the Order plugin cart functionality outside of Blesta via the API so long as the session is maintained.

It sounds like you may need a custom import for your data. Besides the basic name, email, phone, and address settings, clients in Blesta have login credentials, services, invoices, transactions, payment accounts, contacts, etc. You may not have (or need) all of that data to be imported, but it would be necessary to know more details on all of the data that you want to import.

After attempting to provision a service, go to the module logs under [Tools] -> [Logs]. Click the top row next for the Interworx log, and a list of raw Input/Output logs will be shown. If there is a more descriptive error, it will be shown in there. You can share it here if you need some help deciphering it.

For anyone that stumbles on this in the future -- the error indicated a missing class, which was probably because the file didn't get uploaded, or was corrupt. Overwritting the file (the path is shown in the error) with a new version usually fixes the problem.

I'm a little confused. You said you ran the cron manually and didn't have an issue. Then you created a service and ran the cron again to find that the Provision of Paid Pending services froze? I would test it like this: Enable error reporting (you already did this) Disable the cron from running automatically Clear the frozen cron tasks as you did earlier, by removing all `log_cron` records that have a NULL `end_date`. Create a test service in Pending status. Pay the invoice associated with it if you created one. This will now be a 'paid pending service' that the cron will attempt to provision automatically. Run the cron manually so that it will attempt to provision the service. Look at the output of the cron from the Automation page in Blesta. Note any errors If you don't see an error, and the task froze again, then you should see this in the output: Attempting to provision paid pending services. ...but afterward, you should not see: The paid pending services task has completed. This would indicate the task is either 1) still running, or 2) failed but did not generate an error. You should check the module logs under [Tools] -> [Logs] to see if there is any output for the attempt to provision the service. You can click the top table row to show a list of Input/Output. It would be useful to see what (if anything) is available here as well.

@OP Do you know how the service was created? Via order form or manually? Was an invoice created at the time the service was created? Was the service edited by an admin to change anything (dates, etc.)? Was the cron disabled for any period of time?

How did you run the cron manually? By running it manually, I was referring to clicking the "Run Cron Manually" button on the [settings] -> [system] -> [Automation] page in Blesta. Once you click to run the cron, a box will appear that lists logging info for each task that is being run. If one of the tasks leads to an error, the error itself will be shown in that box since you enabled error reporting.

How does your list differ from the countries Blesta already stores?