hpno

Yes, I am using WHMCS for my new company now, after waiting for Blesta. I always support for new products, but Blesta is...

1. If a customer pays by credit card, the payment is processed immediately, and the applied date = the received date = the current date. No problem. However, when a customer pays by an offline method, such as bank transfer, in many cases, the payment is only recorded the next day, not the same day. Then the received date is different than the applied date.
2. The applied date is currently set automatically = the current date, there is no option for bypassing or choosing your own.

Just made at https://requests.blesta.com/topic/set-date-received-vs-applied-date
Please consider. Thanks.

Just made at https://requests.blesta.com/topic/set-date-received-vs-applied-date
Please consider. Thanks.

That I believe is coming in the new domain manager. Domain Manager - We need your feedback on domains

before i begin my request i need a reply for this questios .
what about the actual domains we have , will be listed/managed in the new domain manager ?
it will exist a importer or migrator for all the old domains to the new domain ?
 
 

We are in the process of fully spec'ing out the Domain Manager plugin for 4.1 and would love your feedback. I want to give you a basic overview of what we're considering for the Domain Manager, and get your feedback. We want to resolve the current issues and frustrations with how domains are currently handled. Please understand that the new domain system may not include everything in the first release, but our goal is to build the proper foundation so that it can easily be improved upon in the future.
What is the Domain Manager?
The Domain Manager is a plugin that will be responsible for all things domain related. Think of the Order System, and the Support Manager which cover all things related to orders, and support, respectively.
How will I define pricing?
A pricing grid will exist, likely under Domains > TLD Pricing where the price can be set for each TLD for 1 through 10 years for Register, Renew, and Transfer. This will provide a simple pricing grid, with different price options for Register, Renew, and Transfer. Additionally, special pricing can be set on a Client Group level, which will override the default pricing.
Additionally, domain extras like ID Protect, Email Forwarding, and DNS Management will be options on a per-TLD basis and pricing can be set for these. The customer would be able to check if they want these options during checkout.
Question: Is it sufficient to have a single price of ID Protect, Email Forwarding, and DNS Management for all TLDs, or would you want the ability to set a different price for these extra options on each TLD?
Are domains services?
This is a question that has resulted in much debate internally. My personal thoughts are that domains are very unique and do not easily fit with services. I am proposing that domains be treated completely separately from services. This means there would be a separate table in the database that stores domains and information unique to domains like: Domain Name, Registrar, Status, Date Registered, Date Expires, Management Features Available, Expiration/Renewal Reminders, Last Sync Date, and whether to Auto Renew or not.
If domains are not services, they will not be listed with services. For the Staff area, I propose a new Domains widget on client profile pages. For the client area, I propose a new primary nav link called Domains. The Domain Manager would be responsible for renewing domains, and invoicing for them and services and domains would not appear on the same invoices, even if they are billed on the same day.
Question: What are your thoughts on domains not being considered services?
What about email templates?
The domain manager would create several new email templates, likely to include the following: Domain Registration, Domain Transfer Initiated, Domain Transferred, Domain Renewed, Domain Expired, Domain Renewal Notice (domains listed are going to expire in the next x days).
What about automatic things?
The Domain Manager would be responsible for the following Automation Tasks:
Send expiration emails at the reminder intervals Renew domains that are set to automatically renew Synchronize renew dates with the registrar at a given interval What about Registrar Modules?
The Domain Manager would implement its own module system, and existing registrar modules would not be compatible. The new registrar module system would be drop-in similar to the existing, but these would be enabled and configured under Domains > Registrars. New registrar modules would likely be more lightweight than current registrar modules as the plugin would implement the common features across registrars.
What management features would be available?
This will depend on the specific registrar module, but the following features would be supported:
Register, Transfer, Renew Domain (obviously) with Renew Domain being an option for Clients and Staff Manage DNS for Domain (Get, Update DNS zone records if DNS hosted by registrar) Manage Registrar Lock for Domain (Enable, Disable registrar lock) Manage Email Forwarding for Domain Manage ID Protection for domain (Enable, Disable ID Protection) Manage Contacts for Domain Whois (Registrant, Admin, Tech) Update Name Servers for Domain (Get Name Servers, Update Name Servers) Register Name Servers (Unsupported by many registrars or not commonly done by average users, may be optional for first release) What about existing registrar modules?
Existing registrar modules would be incompatible with the Domain Manager plugin. However, services using current domain registrar modules will continue to work as they do now.
Any bulk features?
We plan to have bulk features for both Staff and Clients. For Staff, under Domains > Browse Domains and under the Client Profile, Domains Widget. For Clients, under the Domains page. Bulk editing/tasks would work similar to selecting invoices for delivery with a checkbox on the left and some options to choose from like Renew Domain, Manage ID Protection, Domain Lock, Name Servers.
I'm certain I'm missing something, but wanted to give you a rough overview of what we are planning and get your feedback. Please let us know what you think!  

The only font which accepts foreign code is: dejavusanscondensed

in the standard orderpage , we can remove one item if there is more items in the cart .
but in the ajax order form (wizard, ajax ) is not possible, only the empty cart option exist . (the whole items)

That's the reason. Thanks.

Wen Transfering a Domain, it must show on the Invoice/Order/Details that is a "Domain Transfer", it may cause confuse to the client (it make me confuse not showing anywehere its a domain transfer).
 
Possible fix, just add a new language variable (Transfer) to be added before the service name if its a transfer.
 
For exemple, if the service is called "Domain .com" in the cart, order details and invoice, will show "Transfer Domain .com - mytestdomain.com (16/04/2014 - 16/04/2015)"
 
To be better, Blesta Should separate complitly the "Services" and "Domains" because Domains dosent work the same way as services do.

Please see CORE-1996
 
This is perhaps the most common migration action that needs to be performed. Rather than have a single, complex migration feature, I think this will solve this issue for most people.

This might be a good option. I know in that case, manual creating is needed. But it can be done easily by a create button, click to that, Blesta connects to server and create an account with existing information from Blesta.
 
Thanks.

Currently, there is no option for re-activating a service after canceling. If customer decides to come back with the same information, now, there are 2 services with the same information, one is active, one is canceled. Doesn't look good from my view.
 
Can you add an option allowing re-activating a canceled service please?
 
Thanks.

Perfect, thanks Michael. Not sure how I could miss that.

You can do that now.
 

 

 

We definitely need proforma invoice issue fixed. I already have question from a customer that if there is anything wrong with system when she got 2 proforma invoices with the same number but different content. 

The reason is at the folder name. It's actually "braintree\_gateway", and system cannot read "\" character. You will need to rename the folder. 

The reason is at the folder name. It's actually "braintree\_gateway", and system cannot read "\" character. You will need to rename the folder. 

Simplest option is to add a few settings under "Display on Invoice" in [settings] > [Company] > [billing/Payment]:
 
[ x ] Date Due for Drafts
[ x ] Date Due for Standard Invoices
[ x ] Date Due for Pro forma Invoices

Personally I would prefer sending the password link. It's time sensitive and allows them to set their own password, which is preferable. Plus, sending a password in email is not secure. I would be open to this. I have had to, on several occasions opened up the client password reset page and entered a customers username to force one of these to them after they had trouble doing so on their own.
 
Thoughts from anyone else?

Alternatively it could just email the reset link to them.  This would probably actually be preferred.  Esentially just a trigger for the forgot password email/process from the admin side.  This prevents the password from ever being in plain text except when the client enters it into blesta.

Just did it

I am considering a feature which could "Restore Defaults" for email templates, and the portal markup, but no such option currently exists. My suggestion is to maintain a backup in case you need to restore the previous values.

Hi,
 
Sorry if this is somewhere able but I do not see it.
I do not like that clients are able to edit all the fields. We should be able to set fields like 'first name' 'last name' 'email' as not editable for clients from the client area).
I would like this to be as the option for admins to configure which fields aren't editable.
 
Eventually if the client really have to change one of these fields they would need to open a ticket and the admin can do this for them.
 
Thanks.