Jonathan

Having an event for services.schedulecancel would be immensely helpful. It'd be triggered upon a service being scheduled for cancellation. We'd also need the inverse event upon unscheduling the cancellation.

Blesta doesn't support this, but +1. Found myself wanting this several times before.

Tested yours in a dev environment and it wreaks havok on invoice reminders.

I guess you could call it a back door. Beats having an office full of people constantly having to 2FA (yes it's not as bad as that with "keep me signed in" and stuff but still).

Can we get a hotfix for this?

For both refund and void commands in auth.net CIM, the API command "profileTransVoid" is sent when for refunds "profileTransRefund" should be sent. This results in refunds failing 100% of the time unless it's an unsettled transaction. To recreate, try to refund an auth.net CIM transaction.

To add to this, a feature on top of this which would allow certain IPs to be whitelisted and bypass this 2FA check would be great.

This is very much a feature request. An in-browser PDF viewer is not a solution to this. +1

Bump on disallowing www or regex capabilities we can enter on the Solus module similar to how the universal module works.

Looks like it was due to a missing autodebit setting in client_settings table. On one install I know how this happened. On the second I have no idea how it wasn't there for some records. It was a WHMCS import FWIW.

I think it would be alright, but perhaps consider putting the gateway name in the text so it's very clear. "Check out now with PayPal/Skrill/<gateway name>" type thing.

I think I found the issue. Will update this post with more info once confirmed.

The date in auto-debit email reminder is also not getting filled. Guess the two things are related. Verified this happens in two different systems, each on 3.5 stable. One system runs PHP 5.6, the other PHP 5.4.

After receiving numerous complaints about the current buttons not being clear, we've found folks really like this one: This should definitely be updated to be more clear to folks trying to make payments via PayPal.

Payments via PayPal even when using the "pay" link directly connected to a specific invoice get added as account credit then applied to the oldest open invoice by the cron. Verified the invoice ID is passed both directions in the API calls. To recreate: Have multiple open invoices. Click "pay" by the newest (as client) and pay via PayPal. The correct invoice info is passed/displayed to PayPal, but the payment will end up as an account credit until the cron runs and applies it. Here's a input/output set from API logs where it didn't apply to the invoice it clearly stated. Output: /callback/gw/1/paypal_payments_standard/?client_id=<123> a:33:{s:8:"mc_gross";s:4:"1.74";s:22:"protection_eligibility";s:10:"Ineligible";s:8:"payer_id";s:13:"KH2WQPLXXVD46";s:3:"tax";s:4:"0.00";s:12:"payment_date";s:25:"12:41:29 Jul 07, 2015 PDT";s:14:"payment_status";s:9:"Completed";s:7:"charset";s:12:"windows-1252";s:10:"first_name";s:6:"<name>";s:6:"mc_fee";s:4:"0.35";s:14:"notify_version";s:3:"3.8";s:6:"custom";s:13:"509422=1.7419";s:12:"payer_status";s:10:"unverified";s:8:"business";s:20:"<redacted>";s:8:"quantity";s:1:"1";s:11:"verify_sign";s:56:"AKhVogKbB40Wjc1IzHO0x4rgsUxoAwZ3YRlNGzQVLxBeMi6Syg9Ntz9D";s:11:"payer_email";s:19:"<redacted>";s:6:"txn_id";s:17:"7RP550164A104845G";s:12:"payment_type";s:7:"instant";s:19:"payer_business_name";s:8:"<redacted>";s:9:"last_name";s:6:"<redacted>";s:14:"receiver_email";s:20:"<ppemail>";s:11:"payment_fee";s:4:"0.35";s:11:"receiver_id";s:13:"4L5A77C6WEY6J";s:8:"txn_type";s:10:"web_accept";s:9:"item_name";s:15:"Invoice #469610";s:11:"mc_currency";s:3:"USD";s:11:"item_number";s:0:"";s:17:"residence_country";s:2:"US";s:15:"handling_amount";s:4:"0.00";s:19:"transaction_subject";s:13:"509422=1.7419";s:13:"payment_gross";s:4:"1.74";s:8:"shipping";s:4:"0.00";s:12:"ipn_track_id";s:13:"7ea093ab47dbf";} Input: https://www.paypal.com/cgi-bin/webscr a:34:{s:3:"cmd";s:16:"_notify-validate";s:8:"mc_gross";s:4:"1.74";s:22:"protection_eligibility";s:10:"Ineligible";s:8:"payer_id";s:13:"KH2WQPLXXVD46";s:3:"tax";s:4:"0.00";s:12:"payment_date";s:25:"12:41:29 Jul 07, 2015 PDT";s:14:"payment_status";s:9:"Completed";s:7:"charset";s:12:"windows-1252";s:10:"first_name";s:6:"<redacted>";s:6:"mc_fee";s:4:"0.35";s:14:"notify_version";s:3:"3.8";s:6:"custom";s:13:"509422=1.7419";s:12:"payer_status";s:10:"unverified";s:8:"business";s:20:"<redacted>";s:8:"quantity";s:1:"1";s:11:"verify_sign";s:56:"AKhVogKbB40Wjc1IzHO0x4rgsUxoAwZ3YRlNGzQVLxBeMi6Syg9Ntz9D";s:11:"payer_email";s:19:"<redacted>";s:6:"txn_id";s:17:"7RP550164A104845G";s:12:"payment_type";s:7:"instant";s:19:"payer_business_name";s:8:"<redacted>";s:9:"last_name";s:6:"<redacted>";s:14:"receiver_email";s:20:"<redacted>";s:11:"payment_fee";s:4:"0.35";s:11:"receiver_id";s:13:"4L5A77C6WEY6J";s:8:"txn_type";s:10:"web_accept";s:9:"item_name";s:15:"Invoice #469610";s:11:"mc_currency";s:3:"USD";s:11:"item_number";s:0:"";s:17:"residence_country";s:2:"US";s:15:"handling_amount";s:4:"0.00";s:19:"transaction_subject";s:13:"509422=1.7419";s:13:"payment_gross";s:4:"1.74";s:8:"shipping";s:4:"0.00";s:12:"ipn_track_id";s:13:"7ea093ab47dbf";} In this case, the payment ended up getting applied to invoice 467083 and not 469610 like it should've been. EDIT: "509422" DOES correspond to the correct invoice that should have been paid, but not the one that was actually paid since the cron did it.

Especially disk space.

To recreate it, change a renew date with "pro-rate" ticked. It doesn't generate an invoice, or a credit. This is for services not using price overrides. The pro-rata previewer at the bottom shows 0 as well which I assume is connected.

Looks great guys!

Invoice searches are doing some nasty temporary tables to disk making them extremely slow. The temp table it's making is about ~80MB for me. SELECT COUNT(*) AS `total` FROM ((SELECT * FROM (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 `client_groups`.`company_id` = '1' GROUP BY `invoices`.`id`) AS `temp` WHERE CONVERT(temp.id_code USING utf8) LIKE '%460669%' OR `temp`.`client_id_code` LIKE '%460669%' OR `temp`.`client_company` LIKE '%460669%' OR CONCAT_WS(' ', temp.client_first_name, temp.client_first_name) LIKE '%460669%' OR `temp`.`client_address1` LIKE '%460669%' OR `temp`.`client_email` LIKE '%460669%')) AS `t_1670833049`; MariaDB [blesta]> explain SELECT COUNT(*) AS `total` FROM ((SELECT * FROM (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 `client_groups`.`company_id` = '1' GROUP BY `invoices`.`id`) AS `temp` WHERE CONVERT(temp.id_code USING utf8) LIKE '%460669%' OR `temp`.`client_id_code` LIKE '%460669%' OR `temp`.`client_company` LIKE '%460669%' OR CONCAT_WS(' ', temp.client_first_name, temp.client_first_name) LIKE '%460669%' OR `temp`.`client_address1` LIKE '%460669%' OR `temp`.`client_email` LIKE '%460669%')) AS `t_1670833049`; +------+-------------+------------------+------+-------------------------+-----------------+---------+-------------------------+-------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+------------------+------+-------------------------+-----------------+---------+-------------------------+-------+----------------------------------------------+ | 1 | PRIMARY | <derived3> | ALL | NULL | NULL | NULL | NULL | 86328 | Using where | | 3 | DERIVED | client_groups | ref | PRIMARY,company_id | company_id | 4 | const | 1 | Using index; Using temporary; Using filesort | | 3 | DERIVED | clients | ref | PRIMARY,client_group_id | client_group_id | 4 | blesta.client_groups.id | 9592 | | | 3 | DERIVED | contacts | ref | contact_type,client_id | client_id | 5 | blesta.clients.id,const | 1 | Using index condition | | 3 | DERIVED | invoices | ref | client_id | client_id | 4 | blesta.clients.id | 9 | | | 3 | DERIVED | invoice_delivery | ref | invoice_id | invoice_id | 4 | blesta.invoices.id | 1 | Using where | +------+-------------+------------------+------+-------------------------+-----------------+---------+-------------------------+-------+----------------------------------------------+ It's making some pretty massive temporary tables on disk. The searches are taking ~30 seconds for a direct match invoice number.

Since you're adding stuff, hostnames should not start with "www." so might be nice to add another rule to prevent that

10000% positive. It's happening across the board on two different installs. It's not hit or miss for certain customers, it's happening to everyone with auto-debit enabled.

This is great, thanks!

All criteria is met so that the customer should get: Auto-debit is enabled, a payment account is setup - the payment account works. It's standard invoicing - not proforma or pro-rata. This is happening on a 3.4.x install as well.

It's the default "invoice created (unpaid)" email template. Nothing has been changed there. This is the "if" statement generating it: Hi {contact.first_name}, An invoice has been created for your account and is attached to this email in PDF format. {% for invoice in invoices %} Invoice #: {invoice.id_code} {% if autodebit %}{% if invoice.autodebit_date_formatted %}Auto debit is enabled for your account, so we'll automatically process the card you have on file on {invoice.autodebit_date_formatted} unless payment has been applied sooner. {% else %} If you would like us to automatically charge your card, login to your account at https://{client_url} to set up auto debit.{% endif %}{% else %}If you would like us to automatically charge your card, login to your account at https://{client_url} to set up auto debit.{% endif %} Pay Now, visit https://{invoice.payment_url} (No login required) {% endfor %} If you have any questions about your invoice, please let us know!

Looks like they're both getting loaded but thanks for the recommendation.