evolvewh

And `support_attachments`, the files of which would need to be deleted too.

With the addition of the new 'System' and 'Company' tabs, it would be a nice improvement if the active tab was shown in a subtle highlighted color. Just a thought but I think it makes it easier for users to know where they are in the system.

I believe we disable the payment button in v4 after it's clicked once. I'm not sure if this would solve the issue with refreshing the page vs double clicking the button though. Still, the confirmation page shouldn't charge the card again if refreshed. Can anyone else confirm? Also, what version of Blesta?

There was a task created and completed for v4.0 to disable the payment button after it's clicked the first time. We've run into the same issue.

With the addition of the new 'System' and 'Company' tabs, it would be a nice improvement if the active tab was shown in a subtle highlighted color. Just a thought but I think it makes it easier for users to know where they are in the system.

With the addition of the new 'System' and 'Company' tabs, it would be a nice improvement if the active tab was shown in a subtle highlighted color. Just a thought but I think it makes it easier for users to know where they are in the system.

Forgot about that. Thank you!
 

Forgot about that. Thank you!
 

support_ticket_replies

nevermind! we found it.
 

Betas and full releases are always available for download in your Blesta account area.
 
Are you using a Beta release for a live site? You mention that a customer tried to login and got the error message.

CORE-2324 We'll take a look, if we can do something without slowing it down, great!

Hi Paul,
Can you confirm if there is a task for this? I don't like the policy but there is no way around it and every other registrar seems to have this already in place.
Thanks and Happy New Year!

Hi Paul,
Can you confirm if there is a task for this? I don't like the policy but there is no way around it and every other registrar seems to have this already in place.
Thanks and Happy New Year!

I would agree that certain fields should be mandatory and if not, make them configurable within the admin area so that we can make them mandatory. At a minimum, First Name, Last Name, Address, City, State, Zip, Email and Phone Number should be required.

Adding a validation to require 2+ or 3+ characters for the first and last name would be nice. We're getting some clients registering with an initial only.

I would agree that certain fields should be mandatory and if not, make them configurable within the admin area so that we can make them mandatory. At a minimum, First Name, Last Name, Address, City, State, Zip, Email and Phone Number should be required.

I would agree that certain fields should be mandatory and if not, make them configurable within the admin area so that we can make them mandatory. At a minimum, First Name, Last Name, Address, City, State, Zip, Email and Phone Number should be required.

any fields in the profile should be in the configurable options.
we have clients registering without zip code and without address, and some modules like registrar domain wont activate the domain if there is no zip code or address, if the domain was purchased at midnight in the morning we found about 90 email only for failed creation service !!!
 

I would think that it applies to any service regardless of the gateway being used.

It hasn't come up much because most services are activated same day. Remind me on this one after we release 4.0 official, this is something we can stick in the next release, it shouldn't be that complex.

There are no days in between. If you set it to 3, it will try the first day (based on Auto Debit Days Before Due Date) and then it will try two more days in a row at your scheduled cron time.

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");  

Awesome. Lines 13 - 18 for anyone else reading this.
 
<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('class'=>"form-control", 'placeholder'=>$this->_("ClientAccounts.ach_info.field_accountnum", true))); ?> </div>  

I should have done this sooner but I have sample data I'm testing with v4.0 b4 and it worked just fine for me to add an ACH account. It's very possible that it was user error on the clients part.
 
Additional Testing
If the user goes and adds ACH as a payment account, it works.
If they login to pay an existing invoice but they don't create a payment account and instead attempt to pay one time by ACH on https://domain.com/client/pay/method/, that's when they're unable to enter a routing number after entering an account number. I tried it by using the tab key and by using my mouse to put the cursor in the Routing # field and neither option works. I'm automatically redirected back to select 'New Payment Details' and 'Other Payment Options'.
This happens on v3.6.2 and v4.0 b4