Tyson

What are the error messages, if any?

This is fixed in CORE-1240 for v3.2.1. You can take a look at the task to see how to pre-patch your install.

The client returned is from Clients::get(), so yes, it does contain the user_id.

Thanks for confirming it, PauloV. This has been fixed for v3.2.1, and there are instructions on pre-patching this issue yourself under CORE-1244 in the meantime.

You would use Clients::create() to do everything--create a client user, create a client, set client group custom fields, setup client settings, add a contact, setup contact settings, and send a registration email. Basically everything that you can do through the admin interface when creating a new client. Clients::add() is simply to create a new client, and that's it. No contact, no settings, all of which are required for proper use in the system. You would need to add that additional information separately, but Clients::create() already takes care of it, so that would be the simpler way to go. It sounds like you need to design a solution that works in your main system for what you're trying to do. If you just need to know which user in your main system corresponds to which user in Blesta, then you can add a new database table, `user_mapping`, that contains two primary fields, `client_id` and `main_system_user_id`. Then insert into that table everytime a client is created. Query it from the main system to determine the Blesta client ID, and use Blesta's API to fetch anything else you need based on that client.

You can't create an invoice for a client that doesn't exist. The client ID is required to create the invoice, and errors are generated for any missing or invalid fields. So yes, you would need to create a client first with Clients::create(), or use one that already exists. You're not going to be able to tie the system-level client or user IDs to your main system unless you integrate a solution where adding a user to either system adds them to both, and they both auto-increment from the same value, and there are never any errors that occur which prevent creating a user on one system when it was created on the other--in other words, it's not going to happen. Not sure why you would need that anyway, though.

Set it in the array you pass as parameters. Invoices::edit() is mostly the same as adding, but specifies the invoice ID to edit. Note that the name and order of the data is important. $api = new BlestaApi($url, $user, $key); $data = array( 'invoice_id' => 17, 'vars' => array( 'client_id' => 1, 'date_billed' => date("c"), 'date_due' => date("c"), 'currency' => "USD", 'lines' => array( array( 'description' => "Line item #1", 'amount' => "5.99" ), array( 'description' => "Line item #2", 'amount' => "3.75", 'qty' => 2 ) ), 'delivery' => array("email") ) ); $response = $api->post("invoices", "add", $data);

The first parameter is the model to call. Your example calls Invoices::add() to add a new invoice.

Thanks, this has been added as CORE-1242.

An hour after the beta ends, you find a bug? Did you plan this?! But thanks for discovering it--CORE-1240. Should be fixed soon.

You could have also set the hostname to home: 127.0.0.1

Take a look at the documentation. You can also take a look at other modules, like the VPS.net module. First define YourModule::getClientTabs(), which returns an array of key/value pairs to reference each tab (as shown in the documentation). Then use those keys as public method names in your module which render the view for the specific tab.

Tickets do support some backend logic for referencing a service, although setting one and showing it in the UI doesn't yet exist.

Have you tried to see if *any* image will appear in the background besides your new invoice logo? Even something small, like a logo image, should appear at the top left of the PDF.

Yes, you need to include the language file before the config file. Don't attempt to use PHP in the JSON file--just set the string: { "version": "1.0.0", "name": "MyPlugin.name", "description": "A plugin like no other!", "authors": [ { "name": "Phillips Data, Inc.", "url": "http://www.blesta.com" } ] } Your language file: <?php $lang['MyPlugin.name'] = "My Plugin's Name"; ?>

You can add language terms to the config file, but I don't think the description can yet be a language definition. Some modules already do this.

Does a thumbnail of the image appear on the /settings/company/billing/customization/ page? Is the uploads directory (/settings/system/general/basic/) writable? Is the GD extension available in php?

Service details are set by the module, otherwise that message appears. What are you trying to do?

Yes, as I mentioned in my previous post, no confirmation is shown when a customer pays via CC/ACH unless that client is logged in. But paying with a non-merchant gateway returns customers to a thank you page. The update to v3.2 shows the customer the same success message after a payment via CC/ACH as they receive when they are logged in. Clients that are not logged in will still be redirected to the login page, however, it will now show the success message regarding the payment. In the future, a separate success page may be a better alternative, but it will now at least be consistent with the current behavior.

The "Shared" and "Assign" IP options for Reseller account types are set by Blesta--it doesn't fetch these via the DirectAdmin API since they are static. I still think there is some issue with connecting to DirectAdmin--user credentials, connection blocked by firewall, package configuration problem, etc. I plan to add in some logging of DirectAdmin packages that are fetched, as currently nothing is logged for those API requests. Once added, you can at least check the logs to see what DirectAdmin responds with, and this should give us a better idea of what's going on. What version of Blesta and the DirectAdmin module are you using?

Thanks for bringing this up. I know if a client makes a payment through a non-merchant gateway they are shown a thank you page afterward. For CC/ACH payments, we simply show a success message rather than a thank you page. I've updated this in CORE-1220 for v3.2 to show the success message confirmation, but a separate thank you page may be a nice addition in the future.

It shows the package name followed by the service name. When using the Universal Module, if a service name is not available, the package name is used. This may be why it appears duplicated. When you edit the Universal Module product, do you have any service fields set? My guess is no.

You can call Services::edit(), and it will then call YourModule::editService(). You can take a look at the VPS.net and SolusVM modules for an example.

It sounds as if Blesta is not able to communicate with DirectAdmin in order to fetch the packages and IPs. This is usually a credentials issue--double check that your username, password, and host name are indeed correct, and that there is no white-space before or after them. It could also be that your DirectAdmin server doesn't have any packages setup for the account type (User or Reseller) you're using.

Not sure I understand the issue you're describing. Your links appear to go to a white page with invalid/incomplete markup, and reference CSS/JS for WHMCS.