Tyson

It's possible we could add another event for applying a transaction. I've created CORE-2791 to look into it.

The language isn't a setting available to order forms. You can change the language from the selector at the top right of the page.

When the API doesn't work the way you expect, you should look at the errors you enconter, e.g.: print_r($response->errors()); See the docs for an example. From looking at your request, you are making a couple mistakes: You're using the "GET" HTTP verb to add something. "GET" [i.e. $api->get(..)] should only be used for retrieving information, not setting information. Use "POST" [i.e. $api->post(...)] You're not passing valid key => value pairs for all values expected by Invoices::add You have "array($service_id,'Desc', 1,1,0)". Is that supposed to be the line items? Why aren't they in key => value format? You have "...'recur_date_billed' => $today, 1)));". What is that extraneous 1 at the end of the list that is not in key => value format? It'll be easier to figure out and avoid issues if you format your source code better: $response = $api->get( "invoices", "add", array( 'vars' => array( 'client_id' => $client_id, 'date_billed' => $today, 'date_due' => $today, 'date_closed' => $today, 'date_autodebit' => $today, 'status' => 'active', 'currency' => '208', 'note_public' => 'Public note', 'note_private' => 'Privat note', array($service_id,'Desc', 1,1,0), 'period' => 'month', 'duration' => 'indefinitely', 'duration_time' => '1', 'recur_date_billed' => $today, 1 ) ) );

array('ticket_id' => $ticket_id, 'vars' => array('client_id' => $client_id, 'details' => 'dab'))

I'm not sure what the issue is with not being able to close the ticket, although it's possible it could have something to do with the support manager pro plugin. In any case, you should revert jQuery back to the original file since v3.3.1 is a different major release from what is included with Blesta and that may break other JavaScript.

The intent is to perform proration separately from a service edit, such as apart of a pricing presenter (which is what we had done in some places, like queued service changes, in v4.0), and overall decrease the number of separate actions that a service edit performs.

If you are unable to access the blesta_id from the session: $user_id = (isset($_SESSION['blesta_id']) ? $_SESSION['blesta_id'] : null); ...then I would suggest following @Blesta Addons's recommendation of creating a plugin. If you upgrade Blesta to v4.3.0+ then your plugin can make use of the new Requestor object that retrieves some relevant information on the currently-logged-in user. If the user is currently logged into Blesta, you should be able to retrieve their user information by creating a plugin with a model that fetches the user from the database, e.g.: class MyPluginUserModel extends MyPluginModel { public function getCurrentUser() { // Load information on the current user $requestor = $this->getFromContainer('requestor'); // Fetch additional information on the current user if ($requestor->user_id !== null) { Loader::loadModels($this, ['Users']); // Fetch and return the user if one exists if (($user = $this->Users->get($requestor->user_id))) { return $user; } } // Return null that no user was found return null; } } You just need to make an API call to your "MyPluginUserModel::getCurrentUser" to retrieve the user. If a non-null value is returned, the username would be available in the "username" property: <?php // Load the API require_once "/home/username/public_html/blesta_api.php"; $user = "API USERNAME"; $key = "API KEY"; $url = "https://blestainstallationurl.com/api/"; $api = new BlestaApi($url, $user, $key); // Fetch the current user's username if they are logged into Blesta $username = null; if (($user = $api->get("MyPlugin.MyPluginUserModel", "getCurrentUser"))) { $username = $user->username; }

With custom code outside of Blesta, you should use Blesta's API. You can use the Blesta API SDK to make API requests with your Blesta installation from your custom code. You will need to create an API user in your Blesta installation to allow API access. I believe you can fetch the user's ID from the php session's "blesta_id" field in your custom code as long as you are on the same domain. Pass that "blesta_id" as the user ID to an API request for Users::get to fetch that user from Blesta. The information retrieved from that request will contain the user's username.

Where are you trying to get the user information at in the source code? You fetch the user via a call to Users::get, but the context in which you do so will differ based on where you're trying to do this (in a controller, model, plugin, module, gateway, custom code, etc.). So we need to know your Blesta version and more context on what you're doing and where you're doing it at in Blesta to be of more help.

The PDO error mode is silent by default. I believe it threw exceptions pre-4.0 so we'll add that behavior back in CORE-2773.

It would be useful to know more information as described in How to Report a Bug. What version of Blesta are you using? If the same invoice is being emailed multiple times, this could be caused by an issue (CORE-2744) introduced in v4.3.0-b3, but that was resolved in v4.3.0 final.

Sure it is, what you've described is exactly the behavior I am referring to.

I think that warning occurs because Blesta attempts to load a certain language definition and then falls back to another if it can't, which is the desired behavior. Unfortunately, php still invokes the warning.

Interesting. I haven't encountered that one myself but we can take a look when time allows

That's not normal. The renew date change to add a new year should be prorated, and an invoice should be created for the difference. I've created CORE-2769 to look into it.

We created https://translate.blesta.com/ to maintain multiple languages across all versions. If you're a contributor, the translator can be set to only translate terms that have not been translated yet, so you can finish them and download a copy of all files with them. Version 4.3.0 will be up on there soon.

When I was referring to the expiration date calculation, I meant the service the module is integrating with, not the module code you wrote for Blesta. From your module source, yes, you are simply setting the years to the number of years for the term from the package pricing, i.e.: $vars['years'] = $vars['years']."y"; That is totally fine. What I was wondering is that once that API request is made, how does their service handle the expiration date? If "$vars['years'] = 2;", you will send 2 years to the API, but will they interpret that as adding 2 years from today, July 19, 2018, or will they add 2 years onto the current domain expiry date? If the current expiry date is February 1, 2020, will setting 2 years make it February 1, 2022 or July 19, 2020?

Does your module set the new domain expiration date as a number of years from today or from the current expiration date? For example, if there are 2 years remaining, and you are renewing for 3 years, does it set the expiration dato to (3 years - 2 years remaining = 1) one year or (3 years + 2 years remaining = 5) five years from now? From your example, it seems like the latter since they renewed it to expire in 1 year but then upgraded to 2 years and the result was (1 year from now + 2 years = 3) three years from now (2018 to 2021). If that is indeed the case, I would think your domain module would need to set $vars['years'] to the difference of the years remaining and the years added.

This sounds like 2 potential issues: The invoice renewed for 3 years instead of 2 (this may be an issue with the module?) The amount due on the invoice for the renewal was prorated to a smaller amount than expected for the service length Can you duplicate this behavior with other services? How about duplicating the issue just for the renewal pricing? If you can provide steps to duplicate the issue in Blesta, perhaps with services using the None module, I may be able to see if this is an issue with prorating service upgrades.

Yes, take a look at Invoices::add, which you can call via the API.

You should create a new custom payment type if you haven't already, under Settings > System > Payment Types. Then when you create the transaction by calling Transactions::add over the API, include in $vars the keys type and transaction_type_id. type would be set to "other" and transaction_type_id would be set to the integer ID representing the payment type you created under Settings > System > Payment Types.

Credits are just transactions that are not applied to an invoice, so you can simply create a transaction.

I think any update we would integrate for this would be to simply require a non-empty format to be set on the settings page.

Oh, so you had changed the location of your Blesta installation a while back? I can see why Blesta never receives the IPN then. It's unfortunate that PayPal does not allow you to update existing subscriptions to change the IPN URL.. are you able to have the old URL forward to the new URL? By default, the URL should be https://domain.com/PATH_TO_BLESTA/callback/gw/COMPANY_ID/paypal_payments_standard/ where PATH_TO_BLESTA is your Blesta web directory and COMPANY_ID is your company ID. GET and POST data will need to be passed along.

In v4.3 you can delete a client and all of it's related information, including services. Packages can be deleted so long as no services exist that use it. So in v4.3, if you delete your test client that has test services, you can then delete the test package afterward.