Jono
-
Posts
376 -
Joined
-
Last visited
-
Days Won
37
Posts posted by Jono
-
-
-
21 hours ago, furioussnail said:
The system marks unsent invoices as sent when you view customer profile.
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
- Paul and Blesta Addons
-
2
-
19 hours ago, Lucas said:
I am just going through an issue with this. The client can easily click the language selector at the top, but it does not save his account to that language, he actually has to login to the user settings and save it in English. Just noticing this after an import of spanish users. I was testing emails and kept getting them in english despite selecting spanish in the selector, that does not work. It works after you login with the user and select spanish as the default language. (I do have spanish as the global language too)
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?
-
On 7/21/2017 at 1:15 AM, limitstudios said:
@Paul can you let me know how the widget loads the scripts and where in the code it does this and renders the graphs; we use nvd3 for graphs/charts in alot of our projects and haven't come across this issue so would be more than happy to look into this and see if we can get a fix for this
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
-
On 8/26/2017 at 5:17 AM, Blesta Addons said:
3 - if not a user and not a staff, check if the sessions has the 'blesta_language' defined, if yes set it in Language::setlang() and Configure::set('Blesta.language') .
Your description is mostly accurate. The one correction is that a client user that is logged in can still use the language selector.
On 8/26/2017 at 5:17 AM, Blesta Addons said:in other place of Blesta, is not worth calling anymore the language to use
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.
On 8/26/2017 at 5:17 AM, Blesta Addons said:Another thing that it should be in consideration, before any set for the language in the session we should first check if the language already installed, if not we should not set in the session or in the configure
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); }
-
6 hours ago, Blesta Addons said:
in some blesta part, blesta ignore the selected language, and use the default company language, like the recaptcha, the knowledge base, and may be other place that i have not yet tested or notified about it.
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?
7 hours ago, Blesta Addons said:i don't know why blesta every time go to get the language from database
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.
- activa and Blesta Addons
-
2
-
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.
- Paul and Blesta Addons
-
2
-
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.
- Blesta Addons and Beav
-
2
-
On 5/23/2017 at 9:06 AM, Adam said:
Any update on this from the Blesta staff?
-Adam
-
On 7/12/2017 at 2:36 AM, Blesta Addons said:
we have removed the manual review, and 2 domains has been renewed . this domain was already ordered.
another strange issue we have found, 1 of this two domains was ordered and activated same day (4-7-2017). then it was paid days after, and the domains was renewed after the invoice was paid !!!
i will put my two cent in this issue, why not just changing the date_added rather than date_renew? if we change the date_added blesta will considerate that the domain was only added now, and then it will affect a true renew date .
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
-
-
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 )
- Blesta Addons and Michael
-
2
-
On 5/22/2017 at 10:48 AM, evolvewh said:
Is anyone else having an issue with the cron task to sync the renewal date? Ours is consistently showing the renewal date of 11 months instead of 12 for every Comodo we sell. We don't sell any other brands so I can't test to see if it's related to one brand or not.
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 dateI'll probably also leave a comment to Nick on the github issue I see you've created.
-
-
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.
- austenite, Blesta Addons and Michael
-
3
-
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.
The password must be at least 5 characters in length
in Support
Posted
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?