Tyson

Yes, the WYSIWYG was automatically "correcting" some HTML, which conflicts with the default markup included with the Portal, so we opted to remove it. What theme changes are you looking to accomplish? Integrating any two independent systems, like Blesta and Wordpress, is going to require some HTML changes at minimum.

Looking at the code, it appears that the nameservers are not included as email tags by the module. You can make them available by updating /components/modules/cpanelextended/cpanelextended.php. Find these lines: 'module' => array( 'host_name' ), update them to: 'module' => array( 'host_name', 'name_servers' ), Once you make that change, the name servers should appear in emails that are sent.

I haven't looked at @cyandark's module, so I don't know if it is a module issue or not. However, you can double-check to make sure the tags you're using are correct in both the HTML and Text tabs of the email template, just to be sure. They should be: {% for name_server in module.name_servers %} Name server: {name_server}{% endfor %}

What's the bug exactly and how does your code change resolve it? What is returned by the module (check the Module Logs for raw Output)? What error do you receive?

If the API URL is derived from the module row, then you'll need both the old module row and new module row to perform the migration internally in your module. You could store it as a service field if you'd like, or determine it from the module rows instead.

What is the bug here? Can you give us more information as described in How to Report a Bug?

You should be able to make this file change to fix it for this module. If it prints out "Name server:", then there is a name server, but it is blank. Double-check the name server is defined when you edit the module row under [settings] -> [Modules] -> (Manage).

Also, don't trust the input is safe for display until you've made it so: <?php $description = $this->Html->ifSet($description_head, "your fallback description"); ?> <meta name="description" content="<?php $this->Html->_($description);?>" />

The module row is not changed for the service because this could cause other problems in many cases. What module are you referring to? If your module has two module rows, and you have both module rows assigned to a single module group, then you should have an option under the Service Information section when you edit the service to select which module row to set on the service. The Reassign Pricing plugin will also update the module row when making a manual change to service pricing.

Your values seem odd. One extra IP is set to 0, and two extra IPs is set to 1, etc. I would expect the values to match, i.e. 0 extra IPs = 0, 1 extra IP = 1, 2 extra IPs = 2, etc. As long as an IP can be selected for every integer in the set (e.g. [1,4]), removing them should function correctly because there is always a valid config option value of 1 lower. I also see that your config option is not assigned to any package groups. Are you no longer using it? In any case, it seems as though the credit-doubling issue may not be a bug with Blesta. If anyone is able duplicate it, then please describe steps in order to do so and I'll take a look again.

@cyandark, can you provide any more details on how you experience this issue, and perhaps include a set of steps to duplicate it as I mentioned above?

This issue is fixed for v1.3.1+ of the Multicraft module (included in v4.0.0 of Blesta) apart of CORE-1967.

Can anyone that encounters this issue provide details on a service (i.e. package and package options) along with steps that can be followed to consistently duplicate this doubled-credit problem?

I'm not sure what you mean by 'incredible security'. You have to choose the best trade-offs that suit you and your business. For example, you can choose to install Blesta on a server with no access to the Internet. That will cripple most attempts to circumvent the system since no one can access it, but that wouldn't make it very useful. You can install Blesta on a server by itself, with the database on another server by itself. Ensure the web server has access to write only for directories that need to be written to by Blesta (typically the temp directory, uploads directory), which are not web-accessible. Other than that, there is no need to rename/delete files, directories, or chmod anything.

Does the fee need to be separate from the package price? If they're flat, it sounds like you could either combine them, or use configurable options. e.g. Service $5.00 and Fee $2.00, then set package price to $7.00 -or- Service $5.00 and Fee added as a configurable option for $2.00 An addon could work as well, but customer's may be able to get away with ordering the service without the addon.

CORE-2104 is fixed for v4.0.0.

This issue is fixed in CORE-2102 for v4.0.0 of Blesta.

The message seems clear to me. What is confusing about the phrasing? The available credits have been applied, but a balance still exists. Please complete this transaction by paying the remainder below. - Credits have been applied - Balance still remains (because credits didn't cover the full amount due) - A statement asks to pay the remainder A warning message is typically shown for inaction, as a notification. The messages shown on the payment page are in reply to actions: two possible ones that can occur at the same time: 1. Apply a credit 2. Make a payment In order to complete the payment process for an invoice, you either need to apply a credit for the total of the invoice being paid, or you need to make a payment for the unpaid amount. In your case, you applied a credit to an invoice (success message!), but it did not cover the full amount. You did not select a payment method to pay the remainder, so you cannot continue to complete the payment process for the invoice (error message!). The total amount due is shown on the payment page, so even after you receive the success message that the credit was applied, and the error message for not selecting a payment method, you can see that the total due has been reduced by the credit that was applied. Why would you want the client to be redirected to the dashboard? They would have to go through the payment process again in the event they made a simple mistake of not selecting a payment method, which is arguably the most common use case. That seems arduous for them. I think accepting payment from customers should be made as simple as possible for them. There's no reason to make it more difficult for them to pay you.

The log is a reply, stored in the language it was written in (company's language), similar to replies from staff or clients. What behavior do you expect to see here?

Why would a new transaction be recorded when you are paying via credit? A "payment" via credit means that there exists a remaining amount from some previous payment, i.e., an existing transaction has not been applied in full. So, no transaction is created for applying a credit since one already exists. If you apply a credit and make a payment at the same time, then yes, a transaction is created in the amount of the payment, but not the credit.

null is the appropriate value for 'no state' in Blesta. If a registrar has some requirements for 'no state', then either the registrar should accept a blank value to indicate 'no state', or the module created for Blesta should otherwise set an appropriate value for that field.

If there is an issue with the auto debit days before due, it would be a separate issue from CORE-2069. Do you send a payment reminder email for upcoming auto-debits? If so, does that get sent on the correct day? What are your timezone settings (in php and in Blesta)? Can you give an example of an invoice that was auto debited the day of rather than a day before? What is the invoice's bill date? You may need to check this in the database (`invoices`.`date_billed` column) to include the date and time. What time of day does your Auto Debit automation task run?

The log message, e.g. The status has been changed to XXXXX . Feb 14 2016 12:55 AM by mohamed anouar ..is two separate definitions. The first sentence can be translated at the bottom of the support_manager_tickets language file (SupportManagerTickets.log.status), while the second sentence can be translated in the admin_tickets language file (AdminTickets.reply.log_date).

I'll move this to the feature requests forum. Also, assigned it CORE-2103.

When paying via credit, the transaction already exists. If the credit does not cover the full amount, then the client will receive the messages you've described--that the credit was applied, but it did not cover the full amount, so additional payment is required. The client cannot pay because there are no methods to pay with--no CC, ACH, or non-merchant gateways. Applying an existing credit to specific invoices is a bit different, but I do agree they should still be able to apply a credit when no payment methods exist. See CORE-2105. This is likely a very uncommon issue to experience. Whether that information is set in the template when payment types are disabled bears no consequence. There is some javascript that checks that information even when it's hidden, so it's probably best to leave it as-is.