Tyson

What you have would work to disable AJAX for numerical pagination links, but not the current page, first, last, previous, or next links. I assume you updated the Blesta.pagination_ajax config file values for this?

No, those module changes have not been tagged, so they were not pulled in for v4.1.0 of Blesta.

Good to hear!

Yes, we could have the applied date be set to the Date Received when recording a payment, but I'm not sure if that alone would satisfy this feature request.

It sounds like someone may have been trying to create thousands of accounts in Blesta from the order form. Creating a client happens in a database transaction, but when that transaction is rolled back the records will not exist in the database, but the auto-increment primary keys will still increase.

It sounds like your Universal Module product has a Package Option called "windows", and when you went to edit the price on the package that uses it, you didn't have a value set for the "windows" field under the Module Options section.

Is this request primarily for an option to manually set the transaction amount applied date? Would this be desired when creating the transaction and applying it to invoices, or at any time afterward? There are two dates associated with transactions: The date the transaction was created (Date Received) The date any amounts from the transaction are applied to an invoice in Blesta (Date Applied) The applied date is not editable since Blesta knows itself when you apply a transaction amount to an invoice, and the invoice may change status (e.g. to closed) once the transaction payment is applied. If you could set the applied date to a past or future date after it had been applied, then the date the invoice was closed and the date the transaction was applied to the invoice may not align.

I'm glad to hear you were able to finally discover what the issue was!

Are there any invoices that have a line item associated with the service where: the invoice has not been closed (i.e. has a null `date_closed` value) the invoice status is active or proforma the invoice has a due date in the past If all those criteria are met, then the service could be suspended. It sounds like the data in the database is fine, yes. Did the service get suspended? If the invoice `date_closed` is set to 2017-07-28 08:26:59, then it should not be suspended --unless-- there is a different invoice for the service that is past due. If the invoice is not in the list, a payment notice email would not be sent for it. If some are still being sent, it is very peculiar and I wonder if something strange is going on.. do those payment notice emails ever get sent from custom code or a custom plugin, or maybe a separate Blesta installation altogether that is using the same database?

The email logs can be deleted over time based on your rotation policy under System -> General -> Basic Setup. Are you sure those payment notice emails are not just so old that they were deleted from the logs? Are you sure the invoice has a `date_closed` set in the `invoices` table? Payment notices can go out for open invoices, e.g., invoices in this list (where the date is the current timestamp UTC): SELECT `invoices`.*, REPLACE(`invoices`.`id_format`, '{num}', `invoices`.`id_value`) AS `id_code`, `invoice_delivery`.`date_sent` AS `delivery_date_sent`, REPLACE(`clients`.`id_format`, '{num}', `clients`.`id_value`) AS `client_id_code`, `contacts`.`first_name` AS `client_first_name`, `contacts`.`last_name` AS `client_last_name`, `contacts`.`company` AS `client_company`, `contacts`.`address1` AS `client_address1`, `contacts`.`email` AS `client_email`, invoices.total-IFNULL(invoices.paid,0) AS `due` FROM `invoices` INNER JOIN `clients` ON `clients`.`id`=`invoices`.`client_id` INNER JOIN `client_groups` ON `client_groups`.`id`=`clients`.`client_group_id` INNER JOIN `contacts` ON `contacts`.`contact_type`='primary' AND `contacts`.`client_id`=`clients`.`id` LEFT JOIN `invoice_delivery` ON `invoice_delivery`.`date_sent` IS NOT NULL AND `invoice_delivery`.`invoice_id`=`invoices`.`id` WHERE `invoices`.`date_closed` IS NULL AND `invoices`.`status` IN ('active','proforma') AND `invoices`.`date_billed`<='2017-08-07 21:38:49' AND `client_groups`.`company_id`=1 GROUP BY `invoices`.`id` If you run that query, does the invoice you're referring to appear in the list?

There will be options for 12, 12.5, and 'Latest' in the updated module for v4.1 but the Plesk API is backward-compatible with older versions, so it should work just fine selecting 11.5 on the module when you're using Plesk Onyx.

Does that occur for an expired token? Typically, failures to validate a legitimate token are assumed to be due to malicious intent on behalf of the requestor (e.g. brute force attack) and no accommodations are made in that case. If legitimate requests can receive a blank page, then yes, we'd like to redirect/cause an error.

The invoice would have to be unpaid for the service to be considered for suspension in the future, so it depends. Does the invoice have a non-null `date_closed`? If there is no `date_closed` date set, the invoice is considered Open and would receive the payment notices. If the email was sent by Blesta it should appear in the email logs. Do other payment notice emails appear in the email logs?

That seems strange. Do you have any custom extensions or custom source code in Blesta that may interfere? Did you encounter it with different packages/options?

Their database does not maintain much data integrity, so some required fields are missing. We're working on updates to our importer to ignore those types of entries and complete the import regardless. The updated importer is currently in beta for v4.1, but if you'd like to try a copy send an email to sales[at]blesta.com and reference this thread.

In the interim you can update: /core/ServiceProviders/MinphpBridge.php At the bottom of the file is a set of TTLs: $ttls = [ 'ttl' => 1800, // 30 mins 'cookie_ttl' => 604800, // 7 days ]; Change the 'ttl' value to the number of seconds a session should last, e.g.: $ttls = [ 'ttl' => 14400, // 4 hours 'cookie_ttl' => 604800, // 7 days ]; Making these configurable from the config file should occur in v4.2.

Yes, those fields are all required. Email is shown simply to show it cannot be made optional. I suppose that could be done for first/last name too, but that was assumed.

It sounds like the pagination container couldn't be loaded. Are you missing /core/ServiceProviders/Pagination.php or /vendors/minphp/pagination/*?

Coupons will only subtract an amount from the total price, not set a specific total price. So if you have different packages at different prices and each one needs to be a total price of $2, you would need to define multiple coupons.

The Mollie API documentation describes a process that mirrors the expectation for a Non-Merchant gateway in Blesta. I'm not familiar with the recurring/subscription process you mentioned, but I would expect it to function similar to subscriptions in PayPal Payments Standard (non-merchant gateway). Payment callbacks from the gateway for subscriptions should still create transactions in Blesta when using the callback URL for a Mollie Non-Merchant gateway. I don't think you need to worry about setting up a Merchant payment account in Blesta or trying to reconcile a hybrid of Non-Merchant and Merchant types (this would be unsupported anyway).

Credits aren't stored, they're derived from the transactions that exist on a client's account that have not yet been applied to an invoice. You can fetch them via the API Transactions::getCredits.

Send everyone an email saying system changes necessitate they reset their password, then provide them a link to reset it.

Why are you trying to get plain-text user passwords? You are aware of the security implications of this, correct? No one should ever know what someone's password is except for that person. User login passwords cannot be decrypted because they were never encrypted to begin with. They are hashed, and that hash only works one way, so you will not be able to retrieve the plain-text version of the password from it. It would be helpful to know what you're trying to accomplish here as there may be a better design you can employ to achieve it.

Thanks for the update. CORE-2410

Sounds very strange, but we'll take a look to see if we find anything. Does it happen mostly for service-related invoices, or can you manually create a new invoice and edit it to encounter the same issue? Do you have any custom code updating invoices? Can you replicate the issue on the demo?