Tyson

Thanks, we'll take a look. CORE-2522

Thanks, we'll take a look. CORE-2521

I haven't seen anything that indicates the new default is a strength of 90, but I would be curious to know if that is the case. You can update the $pool you mentioned above to include uppercase characters, but that doesn't mean a password generated will definitely contain one. The best indicator of password strength should be the password length from a large enough character set. Considering that the password is generated from any character in the pool randomly with equal probability, I would recommend increasing the minimum character length to a suitable number to achieve the desired strength. Without knowing how the strength is derived though, you cannot guarantee a randomly generated password would achieve it. From the examples on the page you linked, it appears each character is given a strength from 6-10, but is subject to a positive or negative multiplier based on other factors. Assuming a strength value of 6 per character in the generated password's random distribution, a 100-strength password could be acheived consistently at a minimum of 17 characters, so I would update the minimum password length to 17: private function generatePassword($min_length = 17, $max_length = 20)

Just wanted to confirm here that any non-fields, like aggregate expressions or custom values, in your SELECT should not be escaped by passing false in Record::select(..fields.., false), as you've discovered already. See the Record documentation for more.

Deleting a client will only delete the client record and the associated user account. The deletion does not cascade across other foreign keys as the data may be useful for reporting, legal, or other purposes. In the future we will likely include the ability to delete all related records at once.

If your cPanel server requires a strength of "90" and the password the module creates is insufficient, you might consider decreasing that requirement on your cPanel server under Password Strength Configuration. I think 65 has been the default value. I'm not sure how that strength value is calculated, so it's difficult to say what changes to the password generator would actually result in a password that meets that minimum strength. If you can find documentation on that let us know.

Are you referring to active services, cancellations, or scheduled cancellations?

Look at the `transactions` table. There is no method to fetch a list of the clients with the most credits. You could, however, loop over every client in the system and call Transactions::getCredits(CLIENT_ID, CURRENCY), then sort them to make your own list, but that would be very slow with the number of queries you would have to execute.

You see that message because you have Blesta configured to "Queue Service Changes Until Paid", so when you save the change, it is a queued service change that takes place once the invoice has been paid. The message will go away when the invoice is paid and the queued changes are finally made via cron. The invoice is the prorated difference between the new term at its new price and the old term at its old price with respect to the next renew date for the current monthly billing cycle. So the current month of $24.95, already paid, covers until Nov 9. The new yearly cost of $299.40 would be prorated to cover only from now until Nov 9, minus the amount already paid for the current month. The result is a cost difference of 13 cents to cover the yearly service for now until November 9, when the service renewal occurs. The next invoice to be generated for Nov 9, 2017 to Nov 9, 2018 would be the full price. If you want to process the service change without charging the 13 cent difference, you can save the service without checking the "Prorate" checkbox, in which case the service will be updated immediately and no invoice would be created. The service will simply renew next time at the yearly term.

There should be a list of items underneath that message that describes the specific issues. Do you not see any? Can you post a screenshot? I suspect that you may have backups setup but they have not run recently.

When you go to edit the client, are there any phone numbers of type "Phone" under the "Phone Numbers" section? The first entry of type "Phone" would be used. The phone-cc field should contain the country code (e.g. "1") based on the client country and the phone number set. It might not be able to decipher it if the country code is not found in the international calling codes (/config/i18.php) list, or if the phone number is already set to an international format, but that format is invalid (e.g. "+23456" when country code is "1").

No, we don't have any current plans to convert text to HTML if no HTML is set. People are usually very particular about their HTML email content, and some may purposefully not want to send any HTML, but text should always be sent in case the user's mail client does not have HTML support.

See my post in the other thread.

The payment URL link requires a token when you're not logged in, which is encrypted data included in the URL. No one will be able to guess it to try to steal account information from the "Copy Contact Information From" option. It is much more likely that someone could intercept the email and follow the link themselves instead. You can update the Invoice Delivery (Unpaid) email template to remove the link to {invoice.payment_url} and define a link yourself to {client_uri}pay/method/{invoice.id}. The client will be directed to login, after which they will arrive at the Make Payment page to pay for that invoice.

That sounds correct. The client mail log does not display the HTML content in the page (e.g. in an iframe). The mail log will show the email TEXT on the page, but when you attempt to resend the email, the HTML and TEXT versions are available in the WYSIWYG and text input fields, respectively.

Are you sure your text version is empty? If it is empty Blesta will attempt to convert the HTML version to text via the Html2Text helper and display that in the UI. But yes, both HTML and text versions are sent but the text version will be what is shown in the UI.

A credit just means that there exists a transaction amount that is not applied to an invoice. If you wanted to create an in-house credit, you would just create a new transaction of type "other" and set the transaction_type_id to the ID that represents the In-House Credit in the system. You can fetch the types (to determine the transaction_type_id) via Transactions::getTypes. So to create and apply a credit: Create a transaction - The transaction amount is now a credit because it has not been applied to an invoice Apply the transaction to invoice(s) - The transaction amount can be applied to 1 or more invoices of your choosing

That warning can be generated if you go to the Edit Invoice page for a client. It is not of any concern, and you need not worry about it. Blesta expects that to occur in some places, but any error handlers can (and should) still mention it, like those logs. Where do you encounter this notice?

Do you encounter this only in the client interface, or in the admin interface too for service downgrades?

The current Offline Payment gateway will allow you to write instructions for clients, however, integrating non-gateway functions, like creating a support ticket, are not supported. You will need to create a new gateway that includes your custom functionality. One of these developers might be of help.

Session values are stored in the database as TEXT types, so they are limited to (2^16 - 1 = 65535) bytes.

The error handler doesn't stop php execution over notices so the cron wouldn't fail to complete if no output buffer exists to flush. There's something else going on that's causing the cron to hang (e.g. waiting for a callback from a module request). Does the cron complete adding all of its services every time?

Html::_ is desired because it prevents XSS while Html::ifSet does not. However, nvd3 does not render the HTML-safe characters correctly. If nvd3 could render HTML-encoded characters correctly that would be great. Another solution could be to use HTML::ifSet but strip any quotes out first to avoid the possibility of the name breaking the JSON format and introducing its own JS via XSS. The graphs failing to load sometimes is a separate issue. The JS for d3/nvd3 could not be loaded before the widget since they are defined and used from inside the widget. I don't see that as a workable solution in any case because it could end up causing a race condition (e.g. maybe the widget loads before the JS loads anyway) that leads to the same issue, assuming the race condition is the issue in the first place. The JS is already set to load in its required order of (1) d3 (2) nvd3 (3) generate graphs.

So you're using it in a plugin? Most plugins make a call to AppController::setPagination($get, $settings, $ajax) to load and set the pagination from the config. The Blesta.pagination_ajax value in the config is used when the third argument, $ajax, is true. This value does not get overridden. If you want to override the AJAX pagination behavior, don't call AppController::setPagination. Instead, load and set the pagination yourself. // Load pagination $this->Pagination = $this->getFromContainer('pagination'); // Set GET params $this->Pagination->setGet($this->get); // Your pagination settings merged with your custom pagination settings $this->Pagination->setSettings(Configure::get('Blesta.pagination')); // Make Pagination available to the view $this->view->Pagination = $this->Pagination;

I tested updating the Blesta.pagination_ajax config value to remove the ajax class (i.e. changed from 'class' => "ajax" to 'class' => ""), and observed the Invoices widget on a client profile to no longer load via ajax when clicking any of the pagination links. Do you not encounter this behavior? I'm using v4.1.