Tyson

So the client did not have a specific autodebit setting, and was inheriting from the client group or company, which was set to disabled? Did a company/system setting for autodebit even exist? Did clicking the Autodebit link on the client profile not toggle enabling/disabling autodebit by adding the field to the client settings? And did it say "ENABLED" when it was not? I'm not sure I would classify this issue as a bug unless one of those answers is yes, however, I tested this myself to find them working properly.

Thanks for the report. I believe you are using those characters (áéíó) in a config option value of the type "Drop-down" (i.e. a <select> tag), correct? Browsers handle values entered for select options differently than they do other input such that select options are still html encoded when sent back to the application. This HTML encoded version of the value that the browser sends does not match the value stored, which is why you receive the error. There are a couple ways we could resolve this issue: Decode the select value whenever it needs to be used after POSTed from the browser. This can be difficult is it can effect multiple areas of the system, and requires knowledge of the type of input field each value came from. Disallow config options of the "Drop-down" type from being able to define characters in an option value that are not identical to their HTML encoded equivalent. This is a much simpler solution (i.e. show an error message), but it limits the characters you can set as a drop-down value, which can have negative implications if you require those special characters. My inclination is toward option #2, despite the value limitation it imposes. Thoughts? This is assigned CORE-1735. Yes, I see this is an issue. I've created a task for us to look into fixing it for the next version in CORE-1734.

What do you think of generic buttons for all non-merchant gateways instead? e.g. "Buy Now", rather than gateway-specific buttons like "Checkout with PayPal", "Pay with Skrill", etc.

Currently, I don't think the coupon applies to a setup fee unless it is for a queued upgrade. There are changes to pricing that need to be updated system-wide before a coupon would apply to setup fees. You could update the invoice and change the discount line item amount to reflect the full discount, but I'm not aware of an easy work-around to get this to occur automatically.

Yes, same as if you create an invoice with $0 due, it is closed automatically.

Yes, the coupon is removed from services if the coupon is deleted. When you manage a service, you can change (or remove) the coupon from that service. For instance, if a customer orders a service with coupon XYZ, an admin can go in and remove that coupon from the service or change it to something else, like "ABC". If you then generate your report based on coupon XYZ, this service would not appear in the list because the service is now assigned coupon ABC. To summarize, there is no knowledge of what the coupon was when the service was created, but only what it is now, at the time the report is generated. There is no "paid" date. For all effective purposes, this is the date closed, as the invoice is only marked closed when it is paid. If you refund a payment from an invoice, then the invoice will be open again. SELECT s.`coupon_id`, ls.`description`, ls.`qty`, ls.`amount`, ls.`invoice_id`, i.`date_closed` FROM `services` AS s INNER JOIN `invoice_lines` ls ON s.`id` = ls.`service_id` INNER JOIN `invoices` i on i.`id` = ls.`invoice_id` WHERE s.`status` = 'active' AND i.`date_closed` IS NOT NULL GROUP BY i.`id`

Sounds good. Curious what you've found.

Although a coupon credit may be added as a line item to an invoice it applies to, the coupon itself is not tied to the invoice or any of its line items. However, coupons are tied to services, and services are tied to invoice line items, so it is possible to deduce that a coupon was used on an invoice because the service(s) that used it has the coupon. This has the potential to be inaccurate in your case, for example, if the coupon on the service was changed or removed after it had been used and before you have generated the report. Similarly if the coupon was not used, but was added after the service was created. Additionally, a coupon may apply when a service renews, so the same service with the same coupon might appear in multiple invoices, possibly skewing your commission results. Join `services` with `invoice_lines` on service ID where the service has the coupon ID you're looking for.

You can create negative invoices in v3.5. It won't automatically create any credits on the client's account for the negative sum, but you can add credits yourself by recording a payment for the same amount.

I think this will be easier once the marketplace is available, where developers can list each of them for download.

You could also update your gateway with a temporary fix such that the values you return as invoice amounts are rounded to two decimal places.

We already have a task (CORE-1516) on record to update the cPanel module to allow for up to 16 character usernames. cPanel does enforce these character limits, and while I agree their username character limit scheme is absurd, it is still a requirement of their system. This is referenced in their API documentation and in a blog post regarding the version (11.44) that they introduced an increase in username length. While Blesta can normally get away with avoiding input requirements that other systems enforce, doing so would pose a large usability problem and have unnecessary performance costs in Blesta, likely to cause both clients and admins headache. Any invalid field data will not be known until the service is provisioned, at which time it will fail. If the cron is provisioning the service, you may not know why the service failed, as the error returned from the module may not be logged, or may be too obscure to determine the cause (e.g. "Error #50191") without requiring manual intervention. These failed API requests and the need for manual intervention after the service should have been provisioned can be avoided by requiring valid information to be entered from the beginning. Some might want to increase the cPanel character limit themselves until an official release is made to the module, in which case this thread may be useful in describing how to do so.

The issue here is that the PayPal gateway is telling Blesta to apply "1.7419" to an invoice when only "1.74" has been paid. This would normally occur for invoices being paid in an amount with greater precision than the currency, for example, if the invoice is calculated from prorated values. If the invoice total were "1.74", then it would be marked paid after payment. A fix will be added apart of CORE-1728 for v3.5.1.

This sounds like an issue brought up in another thread which may be an problem with non-merchant gateways in general.

The screenshot you included shows the record of your defined custom fields, not the values that clients have set. Those are stored in the `client_values` table. However, you need not be concerned with the table structure if you're writing a plugin that uses the API. Simply call the Clients model, which provides several methods for managing custom fields, e.g. Clients::getCustomFields, Clients::getCustomFieldValues

The log of the return values looks alright. Are the invoice amounts being returned arrays? array( ... 'invoices' => array( array( 'id' => 80, 'amount' => 8.0645, ) ) );

Config options require upgrades/downgrades of a service, yes, as they may affect pricing.

Take a look at the comment for CORE-1722.

Clients in WHMCS that are marked 'closed' are made inactive in Blesta during the import.

As Licensecart mentioned, the "Invoice #" is a formatted number which does not necessarily correlate to the system's invoice ID, which your gateway references. The system-level invoice ID can be seen in the URL when clicking the Pay link. My guess is the system-level invoice ID is "80" and the formatted invoice # is "79". You can update the format of the invoice number under [settings] -> [billing/Payment] -> [invoice Customization] -> "Invoice Format". I see you're using a "Stripe JS" gateway. Is that your custom gateway? In your first screenshot, I see that the transaction has not been applied to any invoice. If a payment was made successfully, the invoice should be marked paid, however, the non-merchant gateway determines the invoice and amounts to pay toward it. I would guess that the gateway has a bug or has not been fully implemented to pay specific invoices even though it does successfully take payment.

Thanks for the info. This issue was also reported in another thread, and has been fixed in CORE-1699, currently available in v3.5.0. I would recommend upgrading to the latest version of Blesta, or updating client information from the admin interface instead.

Considering this does not occur in the interface, I lean toward this being an issue with your environment or your plugin. Taxes, even when line items are marked taxable, are only set as taxable if tax applies to the client the invoice belongs to and corresponding tax rules are available that apply as well.

Markdown is used for tickets rather than a WYSIWYG. While it has a higher learning curve compared to a WYSIWYG, many WYSIWYG's don't handle HTML well enough, and Markdown provides a sufficient alternative that is gaining in popularity. Poor WYSIWYG HTML support is the main reason we removed it from the Portal plugin. If you need more HTML support than Markdown provides, then I have to ask--what more exactly are you looking for? PauloV's Support Manager Pro has some nice features, and we will likely implement some of them natively in the future. The same could be said about other extensions that the community has improved upon. However, we don't copy/paste others' work. Instead, we add each feature independently after we've thought about and discussed the best way we think to do so. If you think the Support Manager included with Blesta is not up to par yet, then you might be interested in using some other 3rd-party support system, either PauloV's Pro version, or integrating an off-site ticket system.

Use a module for service management, and a plugin for just about anything else. While a plugin could potentially be created to handle service management, it wouldn't be able to provide the same level of service management as a module in Blesta, unless you completely recreated the entire system's service management through your plugin. For example, Blesta wouldn't tell the plugin that it's adding a service until it has already been added, so any validation/requirements the plugin may impose would be ineffective. If you're just wanting to add a general module that provides server management, a new module sounds like the way to go.

1082 is a separate task. This is more related to 1248 (currently private) that would allow module default config options. Something that will be discussed.