Jono

As long as that value is 5 characters or longer when you submit the form, the error should not occur. Have you been able to recreate this since the first time?

Fair point. That line will not affect the error message, or cause any transaction to be approved that shouldn't, but it will affect whether the logs correctly mark the response as an error.

I'm assuming this occurs occurs on the admin/clients/editservice/ page. The error is based on the password entered in that form. Likely you will want to keep the same password, which should be auto-populated into the field, in plain text as you said. This password should also be shown under the expanded row in the client services widget. If you remove the value from this password field then you will get an error. Are you removing that value?

Confirmed. CORE-2455

I want to be sure I'm understanding. You are talking about using the invoice delivery functionality, in the invoices widget, on the client profile page. When you check boxes for the invoices you want, and then submit the delivery method, the invoices are marked as sent, but were actually not sent. You want the system to immediately display an error message and not mark the invoices as sent. Is this all correct?

CORE-2454. It was a pretty simple fix and will be resolved in v4.1.1

When the client is logged in through the primary user and uses the language selector, the system should update their language setting. If they are logged in as a contact, this will not work since contacts do not have access to user settings. Was the client using the primary login? As far as emails, I believe you are correct in saying that the selector does not impact them unless in changes the client setting. Which emails were you testing with?

I believe the code you are looking for is either plugins\system_overview\views\default\admin_main_tab_overview.pdt lines 33-52 or plugins\billing_overview\views\default\admin_main_overview.pdt lines 89-108

Your description is mostly accurate. The one correction is that a client user that is logged in can still use the language selector. Hmm, I see your point, but the configuration value and the client setting are not the same. So if a user's language is set to English, but they use the language selector to change the language to Spanish, which should be used in the examples you gave. I would still say the actual client setting as opposed to what was being used by the language selector. **Note: If your system is configured such that a client may change their language, the language selector will change the client setting and the two will always be the same. If a contact user uses the language selector it will not change the setting. This is done already. client_main.php lines 880-885: if ($this->isStaffAsClient() || !isset($this->post['language_code']) || !($language = $this->Languages->get(Configure::get('Blesta.company_id'), $this->post['language_code'])) ) { $this->redirect($this->base_uri); }

Just to clarify, is this problem only with the language selector? Or does it apply also to the client changing their language setting? I only looked briefly, but it looks like our recaptcha does not support multiple languages, though it is might be possible for that to be updated. The knowledge base on my installation is working fine with the selector. We are talking about client/plugin/support_manager/knowledgebase/, correct? Do you have the language definitions in your chosen language for the support manager? I'm not really sure what you are referring to here. I believe when ever we are deciding what language to display on a page, we do use Configure::get('Blesta.language'). Is there another circumstance you are talking about?

CORE-2440. Put simply, services use the package name unless they are told to use the module defined service name. Probably this task will update them to do that.

We have been working on implementing a Payment Gateway for Yandex.Money and have a version ready to be tested. Unfortunately, the Yandex test environment is not fully developed and so there are some gaps in the testing we were able to perform. See Paul's forum post here:

The Yandex gateway is now on github. As noted in the README, Yandex is still developing their test suite and so this gateway is thus far untested for completing transaction through Yandex. Transactions have been simulated and functionality local to Blesta has been tested. Feedback is greatly appreciated.

I have confirmed this as a bug (CORE-2447). If you wanted to fix this yourself, in /components/gateways/merchant/stripe_gateway/strip_gateway.php on lines 336, 534, and 956 change if (!isset($response['error'])) { to if (!isset($response['error']) && empty($errors)) { That should prevent this kind of bug from happening.

CORE-2439

The solution I gave only resolved issues in the cron. This error was caused by manual activation which caused the same problem. We have a solution in 4.1.0-b1 to resolve both issues (CORE-2413). The solution is fairly simple. In Services::edit() (for me it is line 1158) change } else { $vars['date_last_renewed'] = $this->dateToUtc(strtotime($service->date_last_renewed . 'Z'), 'c'); to } elseif ($service->date_last_renewed) { $vars['date_last_renewed'] = $this->dateToUtc(strtotime($service->date_last_renewed . 'Z'), 'c'); Just to be clear this is in Services.php

cron.php

Working on a full solution for this. https://dev.blesta.com/browse/CORE-912 was meant to give customers the full amount of time they paid for, but I've confirmed that the changes made there are causing this issue. As a temporary solution for this you can comment out the changes made to the cron for this task on lines 2569-2575: 'date_renews' => ($service->period != 'onetime' ? date( 'c', strtotime(date('c') . " +" . $service->term . " " . $service->period) ) : null )

I was looking into this just now and I think this might be happening intentionally. If we take a look at thesstore_plugin.php on line 212 we see: $end_date = date('Y-m-d h:i:s',strtotime($end_date. '-30 days')); //set 30 days earlier renewal date I'll probably also leave a comment to Nick on the github issue I see you've created.

Created CORE-2313

Quick update. Instead of removing the id you can replace it with something unique like "ach_account" and make the same change to where it says "account" here. This will make the label work properly for highlighting the field. Minor difference. $this->Form->label($this->_("ClientAccounts.ach_info.field_accountnum", true), "account");

Fixed in CORE-2308 In the mean time if you would like to make the change effective before our next release you can modify /public_html/app/views/client/client_accounts_ach_info.pdt where it has: <div class="form-group"> <?php $this->Form->label($this->_("ClientAccounts.ach_info.field_accountnum", true), "account"); $this->Form->fieldText("account", isset($vars->last4) ? str_pad($vars->last4, 9, "*", STR_PAD_LEFT) : $this->Html->ifSet($vars->account), array("id"=>"account", 'class'=>"form-control", 'placeholder'=>$this->_("ClientAccounts.ach_info.field_accountnum", true))); ?> </div> And remove "id"=>"account",

Just finished reviewing @timnboys code and we should get that merged soon. Please let us know if you encounter other problems with the module.

The issue has been addressed in CORE-2221. The decided upon solution was to prevent pending services from making any cancellation calls to the module when they are canceled. This makes sense because when a user(admin or client) adds a pending service blesta will not make creation call to the module.