Chance

The Transactions Model has two methods named add() and apply() which both accept a date parameter. Blesta does store that provided date in the transactions and transaction_applied tables as desired. But when Blesta uses the apply() method to apply a transaction, line #802 of the Transactions Model invokes the setClosed() method of the Invoices Model. The setClosed() method of the Invoices Model does NOT honor the specified date. Instead, it uses current date/time EVERY time. Whatever transaction causes the invoice to be paid in full is the date Blesta should record in the date_closed field for the invoice(s). The date used in date_closed field should be one of: 1) The date specified by admin (or gateway callback), or 2) Default to current date/time (ONLY if #1 is missing (or invalid)). To make this possible, the Invoices Model should accept an optional date parameter/variable in its setClosed() method. When the Transactions Model is used to apply a transaction to an invoice, it should pass the same date parameter to the Invoices Model. In turn, the Invoices Model should set the date_closed field using the provided date, or default date if a date is not passed. Example: $this->Invoices->setClosed($invoice_id, $the_date_transaction_applied) // date is provided so this date used $this->Invoices->setClosed($invoice_id) // no date given so will default to current date/time This issue was discovered after running a WHMCS import. You can replicate this easily: 1) Create an invoice for 10.00, 2) Record a manual payment of 10.00, and set the date received to any date other than the current. Make sure the payment amount matches invoice amount so the invoice will be considered paid in full when saving the payment, 3) Visit the list of invoices. Notice the Date Closed column on this invoice does NOT match the date you entered when recording the payment transaction that closed the invoice. While this is not a runtime type error, it is a general accounting error in that clients viewing their invoices will NEVER see their invoices as being closed on the same day they were paid in full. Not a big deal when we are talking just a day or two between the dates....but after importing over 10,000 invoices over a 15 year period, it looks really strange to see an invoice closed on 12/26/2024 when it was paid in full on 4/16/2016 (8.5 years ago). Just as weird to see years and years of invoices dating back 13 years all being closed on the same day 12/23/2024. This is an easy fix in the setClosed() method of Invoices Model on our developer test install but it should be incorporated as an official Blesta fix. Please consider.

Viewing Tools -> Logs -> Invoice Delivery The Date Sent column shows valid date/time where invoices have actually been delivered. Which is good. The bug is that this column will show whatever the current date/time is for ANY records (paper or email) that have NOT yet been sent. If I am viewing this log, I should NOT see a date in this column if the invoice has NOT been delivered yet. In this scenario, the Date Sent column should be something like 'Not Yet Attempted', or '-', or something similar to reflect that the associated invoice is EXPECTED to be delivered but has NOT YET been attempted/sent. Easy fix is in the /app/views/admin/default/admin_tools_loginvoicedelivery.php file. Line #38 should be changed FROM: <td><?php echo $this->Date->cast((isset($invoice_logs[$i]->date_sent) ? $this->Html->safe($invoice_logs[$i]->date_sent) : null), 'date_time');?></td> TO SOMETHING LIKE: <td> <?php if( isset($invoice_logs[$i]->date_sent) ) { echo $this->Date->cast( $this->Html->safe($invoice_logs[$i]->date_sent), 'date_time'); } else { echo 'Not Yet Attempted'; } ?> </td> The above has addressed the issue for one of our clients but it would be best if Blesta look at this as an official edit of their template file so future updates will have this correction..

@Paul feel free to reach out to me....would be happy to share our implementation of v3, provided that Blesta officially endorses/adopts it (and for free). It currently works with our CMS+ Plugin, but is easily adapted to Blesta core. It provides full v3 implementation via expected action(s) and required score level to determine if successful response. The v3 ReCaptcha class provides the html just like Blesta's v2 ReCaptcha does. Just like v2, v3 provides the client-side script for handling dynamic token validations with expected action (meaning it does provide the ability for client-side to request tokens on the fly). Server-side, v3 ReCaptcha class provides server-side method to validate against that same expected action, and the minimum score required to be considered valid. It is all contained in a single v3 class. The views that wish to use only need to do the same they already do for v2, albeit instead of $this->captcha, it is $this->recaptcha. I am able to speak with accuracy regarding the v3 implementation working as a Blesta core feature because I originally added this v3 variation to Blesta's /core/Util/Captcha/CaptchaFactory and added the v3 class file to /core/Util/Captcha/Captchas/RecaptchaV3. Was able to then go to Settings -> Company -> General -> Human Verification, select ReCaptchaV3, and store the keys. This added the ability for any controller to instantiate v3 just as easily as v2. Our CMS+ Plugin was able to utilize it without issue. I did later remove it from Blesta core and kept separate with CMS+. Mainly because I prefer to NOT mod Blesta core, especially considering that future Blesta updates would wipe it every time anyway so why fight that. v3 is very easy to implement.

It would be nice to prevent emails being sent from system. In our particular case it is because we have some contacts that have a valid email address stored, but we know for FACT the email address is NOT a working email address. Blesta sends emails to these users not caring about the bounce-backs that will occur due to no such mailbox. Other plugin developers may have their own reason to prevent emails being sent. In reviewing the event triggers in app/models/emails.php, it would be very simple to add a variable that plugins can set to prevent email sending, or leave alone to allow emails to flow as normal. It involves changing this block of code currently in /app/models/emails.php, line #558: // Trigger the event $eventFactory = $this->getFromContainer('util.events'); $eventListener = $eventFactory->listener(); $eventListener->register('Emails.send'); $tags = array_merge( $tags, (array) $eventListener->trigger( $eventFactory->event('Emails.send', compact('action', 'options', 'tags')) )->getReturnValue() ); to this block of code (not much difference at all): // Trigger the event $abort = null; $eventFactory = $this->getFromContainer('util.events'); $eventListener = $eventFactory->listener(); $eventListener->register('Emails.send'); $event = $eventFactory->event('Emails.send', compact('action', 'options', 'tags', 'abort')); $event_result = $eventListener->trigger($event)->getReturnValue(); if( $event_result['abort'] ) { $this->Input->setErrors([ 'email' => [ 'sending_restricted' => $event_result['abort'] ] ]); return ''; } if( is_array($event_result['tags']) ) { $tags = array_merge($tags, $event_result['tags']); } The same code could also replace the current code for Emails.sendCustom event trigger. Plugins could theoritecally define their reason for stopping the email by defining a string error message in the abort parameter. I believe the abort variable would need to be handled as a possible array upon return of event in case multiple plugins define reasons to abort sending.

Clearly this is not a bug after all. Figured I should update this to let others know the issue in case they encounter it as well following imports. Issue is 100% related to log group not being set proper when importing from WHMCS. Since all the imported gateway log entries had the same group value, only one PayPal Payments Standard row was being shown in the Blesta Gateway Logs. So EVERY log entry was tied to the same gateway row. Corrected this by providing a unique group value for each entry. The Gateway log lists now shows more than just the single PayPal Payments Standard row this post first mentioned. And filtering works like it should.

content redacted

There are no 3rd-party extensions installed outside of my own 3 plugins. My plugins do NOTHING in admin (other than add some admin menu items and load content IF those menu items are clicked). To be sure they are not interfering, I have disabled them all. The gateway log filter does POST to server, and the Logs model DOES find the matching transaction. The search results are not shown to admin...entire admin logs page just seems to reload. I did programmatically insert the logs_gateway records because the ImportManager plugin does not import that data. Our client wanted EVERYTHING from WHMCS imported over. In doing this, I used Blesta's Logs Model to achieve this. I can see that the log filtering IS matching the search criteria....just not showing the result to admin. I provided the steps to reproduce in previous post.

Further reviewing the POST when filtering the gateway logs......In controller (admin_tools.php) and action (logGateway), it shows that the method (getGatewayList) of model (Logs) DOES return a matching log entry for the transaction being searched for. I see this by dumping the results of line #247 in admin_tools.php and terminating program execution. The single matched transaction is shown. But the AJAX request response to the posted filter does NOT contain the transaction. And the admin page simply appears to refresh, as if no search operation transpired at all.

I deleted all log files in logs_blesta and tried searching for a single transaction. Left date fields blank. I have the PayPal Payments Standard row expanded showing hundreds of log entries as I enter the transaction ID to filter. I click Submit. The page simply reloads with the PayPal Payments Standard row collapsed. I get no search results that I can see. If I click on the PayPal Payments Standard row, it just reloads ALL the gateway log entries. And the logs_blesta directory remains empty.

We have many entries in the gateway log for PayPal Payments Standard. We are looking to find the gateway log for a specific transaction. We visit Logs -> Gateway and filter by Content. We enter the transaction ID of the transaction we want to look up. We have tried entering both a start and end date applicable to the transaction date as well as leaving both filter date fields empty. We click Submit. We get nothing. Watching the console, we see the AJAX call does not return a matching transaction. It appears to simply reload the same page content as before filtering: {"replacer":".content_section","content":"\n \n\t\t\t\t<div class=\"tabs_row\">\n\t\t\t\t\t<div class=\"tabs_nav\"><a href=\"#\" class=\"prev\">&nbsp;<\/a><a href=\"#\" class=\"next\">&nbsp;<\/a><\/div>\n\t\t\t\t\t<div class=\"tab_slider\">\n\t\t\t\t\t\t<ul>\n<li class=\"first\"><a href=\"\/admin\/tools\/logs\/module\/\">Module<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/messenger\/\">Messenger<\/a><\/li>\n<li class=\"current\"><a href=\"\/admin\/tools\/logs\/gateway\/\">Gateway<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/email\/\">Email<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/users\/\">User Logins<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/contacts\/\">Contacts<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/clientsettings\/\">Client Settings<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/accountaccess\/\">Account Access<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/transactions\/\">Transactions<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/cron\/\">Cron<\/a><\/li>\n<li class=\"\"><a href=\"\/admin\/tools\/logs\/invoicedelivery\/\">Invoice Delivery<\/a><\/li>\n<\/ul>\n\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"tabs_content\">\n<div class=\"inner\"><form method=\"post\" action=\"\/admin\/tools\/logs\/gateway\/\" style=\"\" class=\"widget_filter_form\">\n<input type=\"hidden\" name=\"_csrf_token\" value=\"0b4c59bb7966d8d62f3a6753aac0008e5707c5dbf573dc2e07db9e7ba83e3385\" \/>\n<div class=\"pad\"><ul class=\"row\"><li class=\"col-md-3\"><label for=\"string\">Content<\/label>\n<input type=\"text\" name=\"filters[string]\" value=\"7M8076186K676010F\" id=\"string\" class=\"form-control stretch\" placeholder=\"Content\" data-value=\"7M8076186K676010F\" \/>\n<\/li><li class=\"col-md-3\"><label for=\"start_date\">Start Date<\/label>\n<input type=\"text\" name=\"filters[start_date]\" value=\"2023-10-30\" id=\"start_date\" class=\"date form-control\" placeholder=\"Start Date\" data-value=\"2023-10-30\" \/>\n<\/li><li class=\"col-md-3\"><label for=\"end_date\">End Date<\/label>\n<input type=\"text\" name=\"filters[end_date]\" value=\"2023-12-31\" id=\"end_date\" class=\"date form-control\" placeholder=\"End Date\" data-value=\"2023-12-31\" \/>\n<\/li><\/ul><input type=\"submit\" name=\"submit\" value=\"Submit\" class=\"btn btn-default pull-right\" \/>\n<\/div><\/form>\n<\/div>\n <script type=\"text\/javascript\">\n $(document).ready(function () {\n $(\"#admin_tools_loggateway.common_box\").on(\"click\", \"a.ajax\", function(e) {\n e.preventDefault();\n var form = $(this).parents(\".common_box\").find(\"form.widget_filter_form\");\n\n form.find(\"input\").each(function() {\n var data_value = $(this).data(\"value\");\n\n if (data_value != undefined && data_value !== \"\" && $(this).val == \"\") {\n $(this).attr(\"value\", data_value).val(data_value);\n }\n });\n\n form.find(\"select\").each(function() {\n var data_value = $(this).data(\"value\");\n\n if (data_value != undefined && data_value !== \"\" && $(this).val == \"\") {\n $(this).val(data_value);\n }\n });\n\n var action = $(form).attr(\"action\");\n $(form).attr(\"action\", $(this).attr(\"href\"));\n $(form).submit();\n $(form).attr(\"action\", action);\n return false;\n });\n });\n <\/script>\n <script type=\"text\/javascript\">\n $(document).ready(function () {\n $(this).blestaBindDatePicker();\n });\n <\/script>\n \n <script type=\"text\/javascript\">\n $(document).ready(function () {\n $(\"#admin_tools_loggateway .filter-toggle\").click(function () {\n $(this).parents(\".common_box\").find(\"form.widget_filter_form\").toggle();\n });\n });\n <\/script>\n <script type=\"text\/javascript\">\n $(document).ready(function () {\n $(\"form.widget_filter_form\").submit(function(event) {\n event.preventDefault();\n var that = this;\n if ($(this).blestaDisableFormSubmission($(this))) {\n $(this).blestaRequest(\"POST\", $(this).attr(\"action\"), $(this).serialize(),\n \/\/ On success\n function(data) {\n if (data.hasOwnProperty(\"replacer\") && data.hasOwnProperty(\"content\")) {\n $(that).parents(\".common_box\").find(data.replacer).html(data.content);\n }\n },\n null,\n {dataType: \"json\", complete: function() { $(\"form.widget_filter_form\").blestaEnableFormSubmission($(\"form.widget_filter_form\")); }}\n );\n }\n });\n });\n <\/script><div class=\"common_box_content\"> <div class=\"inner\">\n <table class=\"table\">\n <tr class=\"heading_row\">\n <td><span><a href=\"\/admin\/tools\/logs\/gateway\/?sort=gateway_name&amp;order=desc\" class=\"ajax\">Name<\/a><\/span><\/td>\n <td><span><a href=\"\/admin\/tools\/logs\/gateway\/?sort=staff_first_name&amp;order=desc\" class=\"ajax\">Staff<\/a><\/span><\/td>\n <td class=\"last\"><span><a href=\"\/admin\/tools\/logs\/gateway\/?sort=date_added&amp;order=asc\" class=\"ajax desc\">Date<\/a><\/span><\/td>\n <\/tr>\n <tr class=\"expand gateway_list\">\n <td><a href=\"\/admin\/settings\/company\/gateways\/manage\/1\/\">PayPal Payments Standard<\/a><\/td>\n <td> <\/td>\n <td>Nov 01, 2023 4:22:14 AM<\/td>\n <\/tr>\n <tr class=\"expand_details\" id=\"group_c90ec838\">\n <td colspan=\"3\" class=\"subtable\">\n <\/td>\n <\/tr>\n <\/table>\n <\/div>\n \n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n<script type=\"text\/javascript\">\n $(document).ready(function() {\n \/\/ Fetch all gateway logs applied to the given gateway log group\n $(\".gateway_list\").click(function() {\n $(this).blestaUpdateRow(\"\/admin\/tools\/gatewayloglist\/\" + $(this).next(\"tr\").attr(\"id\").split(\"_\")[1], \".subtable\");\n });\n });\n<\/script>","message":null} I would expect that when I filter the gateway logs for a transaction ID, the Content field would map to the data field in DB table and find any log entries containing my search criteria. I can find the transaction log entry simply by using Ctrl + F and entering the same transaction ID into browser's Find field, so we know the gateway logs DO contain this transaction. The log system should allow us to filter on any log field as needed. Blesta v5.9.3 PHP 7.4.33 MySQL 10.2.44

When a NON-PRIMARY contact is in session, and an admin clicks Login as Client, Blesta puts the ID of the staff member into $_SESSION['blesta_id'], overwriting any existing $_SESSION['blesta_id'] value. This produces a problem where code that plugins use to obtain contact data are no longer working because admins are NOT contacts. Steps to reproduce: 1) Login into client area as a NON-PRIMARY contact 2) Do NOT log out of client area 3) Visit admin area 4) Login as admin 5) Load a client in admin portal 6) Use More Actions to Login as Client 7) When a plugin uses the below code to obtain contact data, it fails to pull the correct contact data. It pulls the primary contact, when it should pull the non-primary contact that was logged in PRIOR to Blesta overwriting the $_SESSION['blesta_id'] variable $client_id = $this->Session->read('blesta_client_id'); $user_id = $this->Session->read('blesta_id'); if( $client_id ) { Loader::loadModels($this, ['Clients', 'Contacts']); $client = $this->Clients->get($client_id); if( $client ) { $contact = $this->Contacts->getByUserId($user_id, $client->id); if( !$contact ) { $contact = $this->Contacts->get($client->contact_id); } } } Whether this is by design or not I am not sure. Hence this report. Please advise. Blesta v5.9.3 PHP 7.4.33 MySQL 10.2.44