Tyson

Gateway properties need to be set. This includes a "meta" property. So you should set the meta data to the gateway from wherever you instantiate the gateway. Look at /components/gateway_payments/gateway_payments.php for an example in initGateway.

So the invoice price is 17.22? Thanks for the info.

If Blesta showed 3.5.1 in the footer, then you couldn't upgrade to v3.6.0 because the system was using files from version 3.5.1. In other words, Blesta thinks you're upgrading from v3.5.1 to v3.5.1 (i.e. no upgrade necessary). This only occurs if /app/app_controller.php was not overwritten with the one for v3.6.0. Once it is uploaded, the version shown in the footer of the admin UI will appear as version 3.6.0. At this point, running the upgrade at ~/admin/upgrade/ will upgrade the database to the latest version.

The documentation describes each plugin action you can use to generate navigation links and other widgets.

Can you provide the settings that apply to this particular service? i.e. - What is the service's base price (no tax, no coupon)? - What is the level 1 tax rule that applies? - What is the level 2 tax rule that applies? - Are the taxes compounded? - What is the service renewal price that is shown under the Term column for the service? - Has an invoice been created for this service in its full price, including both taxes? If so, what pricing is shown on the invoice (i.e. sub total, tax rule 1, tax rule 2, total)?

Attempting to upgrade will redirect you back to the dashboard if the upgrade has already been performed. Similarly, if it completes successfully, you will be redirected back with a message that indicates it was successful. Are you sure the upgrade is not already completed? Are you sure all files have been uploaded? Look at the database and check the `settings` table for the setting with `key` = database_version. What is the value? A value of '3.6.0-b1' is the latest version. Also look in the footer of the admin UI to make sure the version is 3.6.0.

PayPal supports partial refunds.

Blesta doesn't currently store any information on your costs, so it is not able to determine profit/loss. Depending on what you're looking for, such a feature could vary wildly in complexity. A simple addition could be to add a field for you to enter a cost on your package (and package options, if any), and then you can just create a custom report from the Report system to calculate profit from services.

If you want to invoke a payment/refund on a gateway via your plugin, I suppose you could use the Payments model to do so. You could also load and instantiate the gateway yourself: Loader::loadComponents($this array("Gateways")); // Load the gateway by its name (my_gateway) and type (non-merchant) try { $gateway = $this->Gateways->create('my_gateway', 'nonmerchant'); // Do something $gateway->method(); } catch (Exception $e) { echo $e->getMessage(); }

Client ID is the system-level (auto-increment) ID from the `clients` table of the database. The number "1500" is the formulated ID code, derived from company settings, which is generally only useful for display purposes. Try using "1" instead of "1500" for the client_id.

Your pagination URI doesn't look correct. Query parameters must come at the end of the URI. 'uri' => $this->base_uri . "settings/company/plugins/manage/" . $this->plugin_id . "/[p]/?feed_id=12345",

Are you referring to the Term column of service listings? e.g. "1 month @ $25.00"? The price shown here is the expected renewal price, at the current time, in its full amount (all taxes, discounts, etc.). If you think this is wrong, can you provide an example scenario that illustrates that point? i.e., package pricing used for the service, taxes that apply, any coupon discounts, etc. It might be possible to see a different amount when the invoice is created (e.g. off by a cent or something) compared to the renewal price, but it shouldn't be missing a second tax rule.

Extensions like modules, plugins, gateways, etc. are independent of Blesta version, so they can work with newer and older versions (depending on feature additions). Incompatibilities arise when Blesta updates the module, gateway, or plugin system that extensions must use. But this would not happen until a major release (e.g. 4.0.0, 5.0.0, etc.)

Sounds like you're working a little too hard. Try to simplify your test a bit and check for errors that are generated while consulting the documentation regarding expected input, e.g.: public function testing() { Loader::loadModels($this, array("Invoices")); $now = date('c'); $vars = array( 'client_id' => 1500, 'date_billed' => $now, 'date_due' => $now, 'date_autodebit' => $now, 'status' => 'void', 'currency' => 'USD', 'note_public' => 'Pub note1', 'note_privote' => 'Pri note1.', 'term' => '', 'delivery' => array('email'), 'lines' => array( array( 'description' => 'Test #1 worked.', 'qty' => 1, 'amount' => '2.33', ), array( 'description' => 'Line Item #2 worked.', 'qty' => 2, 'amount' => '1.33' ) ) ); $invoice_id = $this->Invoices->add($vars); // Errors? if (($errors = $this->Invoices->errors())) { print_r($errors); } else { echo 'Worked #' . $invoice_id; } }

No, there's no plan to allow logins via user IDs. User IDs are not shown in the system, so unless we make it available, admins/clients wouldn't know what ID to login with. Regardless, logging in with a user ID can present ambiguity. For instance, if one person has a username of "2" and a different user has the user ID "2", which person is logging in? Usernames need to be unique to avoid this kind of issue.

I can't create you an example plugin of a capture/refund. This is something you will need to create using your skills as a developer. And how best to do that is up to you. I would suggest making use of the Payments::authorizePayment and Payments::capturePayment model methods which will call your merchant gateway's authorizeCc and captureCc methods.

If the payment was charged using a gateway, and the gateway supports refunds, then you'll have a checkbox option available that will refund it using the gateway. For example, it might say, "Process this status change with the payment gateway (Stripe)".

You'd have to change the core to add that functionality as you've shown in the screenshot. Alternatively, you could create a plugin and do it from a separate location.

Blesta automatically performs redirects to the payment received page whether there is an error or not--you may just want to update the payment received page to display transaction information differently.

I'd suggest creating a new module to accomplish that behavior. The Universal Module is not designed to make RPCs.

I see. As activa mentioned, there are several places you would have to update to add the status. Starting by adding it to the database and making it available from the Transactions model (app/models/transactions.php) in all relevant queries. Then, add it to the UI on the page it should be displayed on.

I'm not sure I understand how allowing a client to belong to multiple client groups would make it easier. Why not set the client downloads (from the download manager?) to both client groups instead?

I'll see if I can take a look at your system this afternoon. As for the email address, yes, as Licensecart mentioned, Blesta does validate whether the email's domain address has a valid MX record.

It's not very difficult to implement deletions. The hard part is in understanding the conceptual ramifications of performing the action. We'd need to integrate better logging of actions like these, especially since deletions are unrecoverable.

What's the reason behind the new status? Why is the normal 'pending' status not sufficient here?