Tyson

Thanks for contributing to the translation! There are over 30 other contributors that have helped to translate Portuguese for Brazil, so I'm sure more will help.

No, you would have to look at each invoice line item and check whether any taxes are set on it.

Blesta only tells SolusVM to add a number of IP address. Blesta makes no distinction on whether the extra IP addresses are to be IPv4 or IPv6. This is left to SolusVM. Whether we can tell SolusVM to create an IPv4 or IPv6 address comes down to the behavior of their Add IP API method. Based on that documentation, there is an "ipv4addr" field that can be set. If that field can be used to indicate that an IPv4 address is desired, then we can add a setting in Blesta, when adding an extra IP, to choose IPv4/IPv6. However, if that field requires a specific IPv4 address to be entered, as the documentation appears to imply, then there may not be anything we can do. I am not aware of any API method to retrieve a list of available IPv4 addresses from SolusVM from which we can then choose one and add it to a service when adding an extra IP address.

Personally, I'm not opposed to using language definitions for gateways. Can you give an example of a gateway name that is written differently in different languages? Usually, at least most of the time for English, the name of something is always written the same no matter what language it originated from. The reason names don't use language definitions now, besides what I already mentioned, is due to the performance trade-off. Most people don't really consider the amount of time and CPU cycles required to load more language files on several other pages wherever gateway names, module names, etc., are shown.

The +B looks like a 3. Makes me think it's for Blesta v3. I think it would look better without the "Your Land For Blesta Addons" text. There will be another land for Blesta addons when the marketplace is live.

Can the solution be shared? Someone else may find it useful in the future.

I can see why the first option would be best for you, but in a general case, I don't think we can assume that every staff member that views a client profile is able to read the profile in the client's default language. The second option you mentioned is essentially what I described earlier. Another possible option is to allow staff to set what languages they read/speak in their profile, and if the client's default language is also one of those, Blesta can show the client's default language by default when the staff logs in as the client.

While using strftime would use the locale that is set, you still have to first change the locale with setlocale to match the language someone is using in Blesta. However, setlocale is not a thread-safe function. When multiple people are using your site at the same time, they may see dates in someone else's language. Worse, it will be an intermittent issue that comes and goes depending on other people using the system. There is a way to use internationalized date names correctly, but it requires a newer version of php than our current minimum requirement of php 5.1.3.

You could, but that still doesn't mean it's a valid CSR if it passes that rule either. I'm not sure if GoGetSSL's API provides a method to validate the CSR, but creating a rule that checks that would be the best route to go.

The only validation on the CSR field is that it is not blank. If a customer enters an invalid CSR, I don't think GoGetSSL will accept it when attempting to provision the service. Ideally, the CSR would be entered after the service is setup in Blesta. If there is a way to validate the CSR is correct for the domain at that point, then that would be the place to do it.

Date descriptors like the month name or day of the week use the system's default locale. You can set the default locale in your php.ini file. It is probably set to en_US by default. You could change the locale so that date descriptors will appear in French, but then they would always appear in French regardless of the language you're using in Blesta. There is no internationalization support for the date descriptors based on language selected in Blesta. You could either set an appropriate default locale suitable for all users as I mentioned above, or not use date descriptors like "F" and "l" in your date format.

If you want it to only affect the pagination of a single page, then you would need to update the controller for that page to set the results_per_page that you want to use.

Packages can belong to multiple groups. You can retrieve them from Packages::getAllGroups.

I think there should be a way for admins to view a client in the client's language, but we can't require this to be the default behavior, as we can't know whether the staff is able to read that language. There would have to be a way for staff to choose a language to use. We could use a language selector as I mentioned above, and indicate in the selector which language the client uses by default, e.g. ("English", "Espanol (default)", "Deutsch"). Or we could have a link at the top of the page, similar to the "Return to Staff Portal" link, that toggles between the staff language and the client's default language when you click on it.

Good to hear you got it working. The default number of results shown per page is set in the config file at 20. You can override it on a specific page by setting a new value for pagination (as you did). However, if you intend to use the default value from the config file you may want to debug why the pagination is not showing in the client UI. It should function exactly as, say, the Transactions widget's pagination. The fact it didn't appear is strange, but all of the code you shared looks fine to me, so it may be an issue caused somewhere else.

What do you think of using a language selector like CORE-1320 as a staff member? Do you think that would solve the issue of not being able to view the client UI in the client's language?

What you've described is how it works. Yes, it sounds like what you have setup should be working just fine.

If you don't want to update core files, you can write a plugin that adds a widget to the client dashboard similar to the Invoices, Transactions, and Services widgets. Otherwise, you'll need to update core files to make the data you want available to that template. To do so, open the ClientMain controller in /app/controllers/client_main.php. Find: $this->set("client", $this->client); Above that line add: $this->set("max_due_currency", (isset($max_due_currency) ? $max_due_currency : null)); $this->set("max_due_amount", (isset($max_due_amount) ? $max_due_amount : null)); Open up the client_main.pdt template you mentioned, and use the CurrencyFormat helper to format the amount due, e.g.: <?php if ($this->Html->ifSet($max_due_currency) && $this->Html->ifSet($max_due_amount)) { ?> <p><?php echo $this->CurrencyFormat->format($this->Html->ifSet($max_due_amount), $this->Html->ifSet($max_due_currency));?></p> <?php } ?>

Pagination requires the HTML helper. Calling the build method only builds pagination if you had previously set data into it from which pagination could be built, for example, the number of total results and the page you're currently on. Also, by default, pagination doesn't show if there is only one page of results. You should check the settings you have configured for pagination.

The only automatic voiding done for an invoice that I'm aware of is only in relation to queued service changes. When a queued service change is canceled, the associated invoice is voided. This behavior wouldn't apply to suspended services. I think more information is needed. Can you duplicate this behavior for other suspended services? If so, can you detail the steps you went through to duplicate it? Service and invoice details may also be useful to know in debugging the problem.

How can you see the invoices are automatically voided? I think the only time an invoice is automatically voided is when a service change is canceled as Licensecart pointed out. If you're finding a voided invoice that was not done manually, you may need to check any third-party extensions to see if they have the ability to void invoices.

What's the status of the invoice? Was it voided?

What version of Blesta are you using? It may be best to upgrade to version 3.5.2 as there were a couple changes to Blesta that can affect non-merchant gateway payments. One is whether an error transaction is recorded when Blesta receives an invalid response (CORE-1747), and another is the addition of currency precision to resolve issues where minute price differences would cause an invoice not to be paid (CORE-1742), similar to what you've described.

If the intention is to update the routes.php configuration, then the file itself will need to be updated, or you would need to use vQmod. Alternatively, you could build routes into an .htaccess.

I'm not sure it's possible to add an item to the cart outside of the order system. You could try crafting some specific POST data to the order's /config/ page to imitate the current functionality. You'll need to look at the order plugin Config controller.