All Activity

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.

Does this happen on an unmodified installation with no 3rd party extensions installed? I've tried and have been unable to reproduce this. When I search the gateway log, I'm seeing the expected results. We will need steps required to reproduce.

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.

The pagseguro gateway is not finalizing the sale, I tested and redid the configuration several times and it continues to give the same error. screenshot of the reported error

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.

If you set all the service to the same renew date, they will be combined on the same invoice by default.. unless you have disabled this feature. Separately, we would consider a feature request for combined monthly billing for services that do not have the same renew date. https://requests.blesta.com

I tried to reproduce this with Stripe Payments (Not able to test with PayPal Payments Standard, but it shouldn't matter). Using the filter option, and entering the transaction # in the content box (Not selecting anything for dates), and clicking Submit did return the gateway log that contains the transaction # in the response data. If the transaction # is included in the gateway log for PayPal, it should find a match, it does appear to do a LIKE search on the response data. I would check ../logs_blesta/ logs to see if there are any errors while performing the filter operation.

We are pleased to announce that we have released another version of Blesta ClientX Realease Date 16-April-2024 Blesta Clientx V1.3.0 Bug -> Order Form Description is loading group image 2 times -> Fixed Improvement 1 -> Blesta 5.9.3 Compatible 2 -> CSS Optimized https://whmcsglobalservices.com/clientarea-template/clientx-blesta-client-area-theme/

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

Blesta 5.9.3 regular PHP 8.1 When you go to a client, then click View Mail Log, then click on a message, the content of the message shown does not match the email actually sent to the client, if you have changed the email template. I thought the email template editing process was broken, but I confirmed via server logs the client received the correct message. It's just not being shown correctly under the Mail Log in Blesta.

@Paul I would like to add two feature requests. One minor and one large. I cannot put images into the requests topic so I will copy text from here and reference here. Also, the minor proposal gives context to the major proposal and the major proposal involves use of the BTCPay API, as mentioned here. So, maybe it is appropriate to link to here to start off and provide context. Minor proposals for enhancement of the Virtualmin module Proposal at https://requests.blesta.com/topic/minor-enhancments-of-the-virtualmin-module 1) Add in an extra text box below the 'Configurable Options' of an order form similar to Domain option below (which is not an option, it is a requirment). Call the option 'Site Header Text'. If you take this value and pass it to Virtualmin in the remote API version of the call to 'virtualmin create-domain' as parameter --content then this text will appear in the header text of the created default web site. The reference for the API is at https://www.virtualmin.com/docs/development/remote-api/#the-remote-api and the reference for individual commands of the API is the same as for those of the CLI. This means call is https://www.virtualmin.com/docs/development/api-programs/create-domain/ is the reference for create-domain API call. The reference does not explain what is done with the --content parameter and the reference to a filename does not appear to make any sense in [--content text|filename] with regard to code paths I followed in Virtualmin source code. Well, I have told you now what it does. The text of --content goes at the top of newly created web sites in big bold letters. 2) Also please pass in a --desc parameter with create-domain with automtically constructed text, such as "Created through Blesta, order ID: xxxx". This will appear in an admin screen in Virtualmin for the account holder and the text can be edited by the account holder. 3) The API refenece page above has the following text: "The output from remote.cgi is plain text, including the command-line program’s output and an exit status line indicating success or failure". Please make sure Blesta uses it. For example, during tests Blesta got told to create two different accounts with the same domain name. Virtualmin freaked and refused. Blesta thought everything was great and failed to provide any notification of failure. It might be wortwhile to check beforehand if the domain already exists. Major proposal for enhancment of use of BTCPay API Proposal at https://requests.blesta.com/topic/major-proposal-for-enhancment-of-use-of-btcpay-api-in-a-new-module The proposal is big but the text of the proposal is small. Pease add in an additonal module to allow creation of BTCPay stores that works in the same manner as the Virtualmin module. It would be great if the module could also be used to provide an addititonal service to order in other order forms, but this may be asking too much. The reference for users for what to do after user level store creaton is at https://docs.btcpayserver.org/CreateStore/. Please include a field for the store name. Suppose a user filled ''My New Store Created By Blesta". What an account holder will get when they login is in image below. They can go into Settings to alter the default currency. More information about what to do can be provided in links in the welcome email, as configured by the Blesta admin. The API reference to create a new store is at https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Stores_CreateStore

Maybe not a "bug" but is not done correctly, Blesta module not should managed coins if not btcpay store, For example if btcpay support 3 coins blesta module should be display that three coins if two then two etc. I already create feature request as i say two years ago and ignored or not care https://requests.blesta.com/topic/btcpayserver. You need to see how whmcs handle their module and you will see what is blesta module lacks.

I think we should be getting more precise. For example, what exactly does default mean? There is no simple answer. Here is my attempt at providing a precise answer. Below is the default screen when a manual invoiceis created in BTCPay. 1. The Supported Transactions Currencies appears with three ticked boxes when Lightening is enabled and when LNURL is enabled 2. If Off-Chain and LNURL is selected then only the Off-chain will appear in invoice 3. If Combined URL/QR is chosen then only one QR box will appear. 4. The equivalent in the API is the "paymentMethods" array. 5. If the "paymentMethods" is not set in the API then this appears to be equivalent to choosing all available transaction curriencies, as BTCPay calls it. 6. The 'Default payment method on checkout' ABOVE provides a single choice way to override the setting BELOW in Settings, Checkout Appearance 7. The "defaultPaymentMethod" string in the API is, I guess as in invoice creation, really a way to say, no I don't really want the store default. 8. The upshot of all of this is that not setting either of the two API variables we (hopefuly) get a clear outcome: all available transaction curriences (unless LNURL clashes with Off-Chain) and no override of store default 9. Now what does 'store default' or its overide mean in practical terms? 10. If a combined URL/QR it means nothing. It can't, as there is no choice to make. 11. If not combined then it decided which of the two QRs is shown, with the chosen one having it's button in green. 12. A complicating factor is that if store settings indicate to show URLs as copyabe text, then they will both be shown below at the same time. So what happens if we do decide to pass a "paymentMethods" array and "defaultPaymentsMethod" string in the API call? Hopefully the answer is simple: that it corresponds to making alterations in a corresponding manner as with the manual invoice creation. With regard to issue with @Kurogane and alt coins, my guess is that not setting the two parameters mentioned in the API call will give him what he wants. Maybe he could let us know the results of commenting out line 268, as I did.

@John Heenan I'm not sure I have a complete understanding of this, but I've created the following task if you want to review and advise whether this is the proper solution. https://dev.blesta.com/browse/CORE-5168 @Kurogane I don't see a bug here at all, if these altcoins are plugins to BTCPay Server and not configurable out of the box, then they fall squarely under the category of feature request. You can make a feature request at https://requests.blesta.com to recommend adding support for additional coins.

Altcoins FAQ for BTCPay at https://docs.btcpayserver.org/FAQ/Altcoin/ It looks like up to nine altcoins can be added. There are currently integrations for 14 altcoins.

I report this "BUG" two years ago blesta module only accept BTC as payment even if the store allow multiple coins. This is competitor module and this is correct way blesta should be display. Module should be display store coin supported instead of just accepting BTC/LN.

I should also add that in the context of Blesta, sending a LNURLPAY makes little sense. It's main advantage is that payments can be made without generating an invoice beforehand, as LNURLPAY allows invoices to be generated on the fly.

I now have better information on how BTCPay behaves with settings and how the very popular Blink wallet behaves. There is bizarre behaviour can have a profound effect if Blesta invites admins to override settings. The BTCPay default payment method is set from Settings, Checkout Appearance, Invoice Settings BTC (LNURL-Pay) is only available if it is enabled from Lightning, Settings, Enable LNURL (image above). For Lightning, BTCPay will only every show an LNURLPAY or an Offchain fully encoded invoice, NOT BOTH ON THE SAME INVOICE. LNURLPAY has advantages over Offchain, but not when a regular invoice is being issued. In BTCPay, if a PARTICULAR invoice is specified to to show both LNURLPAY and Offchain encoding it will only show the Offchain encoding: the LNURLPAY setting is overriden. So checking all three below for a PARTICULAR invoice is pointless when generating an invoice as only Onchain and Offchain will show in the invoice, not the LNURLPAY. The effect is the same whether the unified on-chain and lightning URL/QR code is enabled or not (image above) The following is subtle with the Blink wallet. Blink will read LNURLPAY if not part of a unified QR code Blink will read Offchain if it is part of unified QR code with Onchain Blink will not read LNURLPAY if it is part of a unified QR code with Onchain. This means show a unified QR code with Onchain and LNURLPAY to Blink and Blink will choose the slow and expensive Onchain. So if a Blesta admin decides they will be smart, allows unified URL/QR, allows Offchain and LNURLPAY, but not Offchain which overrides LNURLPAY in BTCPay, and a customer pays with a Blink wallet, guess what, they are forced Onchain with a slow result and unnecessary expense.

Or the choice of what the customer sees, including the default choice or even no choice, could be left to the Blesta admin.

A refinement. Blesta could add to a customer form two choices, defaulting to first: Pay with BTC Onchain (this can delay order processing) Pay with BTC by server default (may or may not also include BTC Lightning) Or this could be left to the Blesta admin as a choice for all customers

A BTCPay method is set by API call if it includes an option to set it. I don't see how it has anything to directly do with a Blesta button. The buttons a customer sees on the final payment screen are BTCPay buttons, not Blesta buttons and what they are depends on what the API call instructed. To eliminate confusion, there is the Blesta invoice and the BTCPay invoice. The only way to make a payment with BTCPay is to 'create an invoice'. So there are two invoices involved. BTCPay really considers itself to be a store that includes a payment gateway. With Blesta we are short cutting the BTCPay store part and going straight to make a payment through generating a second invoice with an API call to BTCPay. Also the 'invoice' terminology is core with Lightning. Also the concept of an invoice expiring is central to Lightning. Which means if a customer does not pay before expiry then another invoice has to be generated with BTCPay. A regular BTCPay only recognises BTC crypto. Its payment methods are BTC Offchain and BTC Onchain. BTC Offchain recognises payment through a LNURL and through what I suppose is traditional Lightening, through a choice of both and also through a BIP21 unified Offchain/Onchain URL. Also all methods have QR codes. Why add to the confusion? Personally I think Blesta should stay out completely of changing BYCPay store default choices and make it very clear the payment method is chosen by the BTCPay store default. It only adds a second layer of confusion otherwise. I think Blesta should very prominently display advice to check defaults, to test well and also advise that Lightning is very convenient for customers (fast and tiny fees) but requires additional set up to using an onchain xpub address and that a hot onchain wallet should never be used with BTCPay. I think helping Blesta customers feel safe about using BTCPay is important. You could offer a choice to either force BTC Onchain use or to allow BTCPay store default. If you default to force BTC Onchain then this is backward compatible and you don't have to make any prominent announcements. You are requesting I provide opinions about what is best, something I cannot do.

Ok, to see if I understand: The payment method is set by the Blesta button, so that the BTCPay invoice generated requires payment via that method. BTCPay supports (Bitcoin or Lightning, or any of the 4 you mentioned) as returned. You said: But it appears that it may also be possible for us to allow the payment method (From the 4 mentioned) to be set in the gateway configuration in Blesta) so that the payment button generates a BTCPay invoice in the desired method. Or, we can simply remove the option and allow the client to select it. What path would you recommend? Allow the payment method (of the 4 options) to be set in the gateway config in Blesta, so that the button specifies that method when a BTCPay invoice is created. Or, comment out the line so that the client is presented with the options? Curious what you think is the best way to go. Do you think admins want to force the client to pay with Lightning or BTC on the gateway config level, or let the client choose? I assume that the client will only be able to choose from methods that have been configured in BTCPay Server? So if BTC is the only option, then only it will appear.

Still available - Will go as low as $150.

I have tested with a new store with Lightning not enabled and the behaviour was fine with line 268 commented out. You ask as to best solution with my current config. No, if all wallets are BIP21 compliant. But they are not, including the world's most dominant Lightning wallet by far: Blink based wallets. Odd that https://bitcoinqr.dev/ refuses to even list Blink wallets in its compliance test conformity list. I deliberately took the unified BTC/Lightning URL and QR image option off during tests as I needed to see a clear visual distinction between BTC and Lightning during tests. Until I have made tests with different popular Lightning wallets, I will keep the distinction. Blink based wallets may not be happy with the unified BIP21 appoach, maybe for good reason. I will need to complete more tests to confirm some earlier results.