John

Unfortunately the tab does not have any idea about whether you can access the content of that page. I agree this would be a great feature, but it's much more complicated than it appears.

I really like this suggestion, it's unfortunate it takes a lot of work to do this though, for not much gain.  In terms of UI, a user should never be able to see options that are not available to them. 
I wouldn't mind seeing this in a future version, but it's not urgent. 

+1 for future versions.

Plugins and other extensions should be backwards compatible yes.. but you should *test* this. We've run into some issues where our plugins were not working properly and have had to make adjustments to the minPHP bridge. As Mike mentioned, you may want to update your buttons in your plugins to use the new Bootstrap ones, but if you don't they should still work.
Test, test, test, everything you can think of. It's possible we missed something, and being a major release, this version requires extra scrutiny.

Warming up the beta forums. We've scheduled Beta 1 to start next Thursday, September 15th. We've had quite a few issues pop up with regard to the minPHP upgrade, and we're really close to having those all resolved. That's not to say we've caught everything. Being a major release, please consider 4.0 beta 1 more of an alpha, and do not under any circumstances run it in production.
Looking forward to it!

immediate suspend and cancel can load a the browser to freeze .
to add them as a cronjob , it need some code modification and code addition .
+1 , but if it need a more time i prefer wait until v4.2 or 4.10 .

Schedule Cancellation exists, are you asking specifically for Cancel (An immediate cancel) and Suspend (An immediate suspend?) We were comfortable adding a Schedule Cancellation option because the cron processes these. If you bulk-select a lot of services to cancel or suspend, it's possible the browser would time out before it was able to complete the operation on all of the selected services.

Add the possibility to cancel and suspend services in the bulk options.

Blesta version 4.0.0-b1 (BETA 1) is now available. You can download it from right here (Client Area Login Required).
This is a BETA release. Beta releases are not considered stable enough for production use, and are UNSUPPORTED. DO NOT INSTALL IN A PRODUCTION ENVIRONMENT.
Please report any bugs you find in the v4 beta bug forum.
Installing Blesta

See Installing Blesta in the User Manual for instructions.

Upgrading Blesta

See Upgrading Blesta in the User Manual for instructions.

Release Notes

See Blesta Core - Version 4.0.0-b1.

For older releases see all Change Logs.

I do miss this feature from v2.5. It's good for staff to be able to specify which server to use when manually provisioning.
 
See CORE-2156

cpanel working well , but in a big companies the actual cpanel plugin need some tweaks .
actually, the module create account in the server selected in package , or if module groups created , the cpanel module use "first" methode free server to provision the account in it .  so no options for staff to choose wish server to host the account .
so , what i suggest a option to choose wish server to host the account , if not choosed then use the default method to host account .
when thinking in this request make in consideration a park of  5 or 30 servers dedicated to host website . and some times we need to make a manual activation for account in some servers .
another time v2,  was this option

I am using piping
But I don't want to have 12 google apps accounts. I want 1. Along with 12 aliases on it. 
admin@domain.com is the main account. info@, sales@, whatever@ are the aliases. I forward the aliases to the blesta domain. 
Alias1@google-apps.com forwards to alias1@blesta-install.com, alias2 forwards to alias 2 and so on
However, if I sent an email to alias1@google-apps.com, it forwards the email to blesta, my server has logs of it. However, Blesta doesn't pipe in the ticket. It sends the "Ticket Bounce" error message template. So it actually reaches Blesta, but Blesta rejects creating a ticket for it. Departments are set to accept all emails, not just customers. 
However, if i email alias1@blesta-install.com directly, the ticket is piped in just fine.
That's what I want to know. What's going on in Blesta to refuse creating a ticket the first way. 

Piping is instant.
You can forward email to another domain that accepts mail on your server and use piping instead.

Instead of piping, try using IMAP, and set up your Gmail rules like the following:
department1@example.com gets put into a folder called DEPARTMENT1
department2@example.com gets put into a folder called DEPARTMENT2
etc....
Then, in the Blesta install, just change the IMAP folder for each department from INBOX to the department's folder.
What are the benefits of piping compared to IMAP for you? Currently, we have it set up this way, and no complaints.

Only reason is SLA's. Up to 5 minutes before a ticket is seen equals up to 50% of the reaction time for certain SLA segments in my case. 
Piping only takes about 30 seconds to a minute, so that helps a lot when it comes to response and reaction times. 
If only it were so simple to use IMAP in my case  

Forced SSL is the best part imo.
Already found some broken ones though
On the lounge page (https://www.blesta.com/forums/index.php?/forum/17-the-lounge/) I got 4 ssl errors
Mixed Content: The page at 'https://www.blesta.com/forums/index.php?/forum/17-the-lounge/' was loaded over HTTPS, but requested an insecure image 'http://www.blesta.com/forums/uploads/profile/photo-thumb-499.png'. This content should also be served over HTTPS.
index.php:2404 Mixed Content: The page at 'https://www.blesta.com/forums/index.php?/forum/17-the-lounge/' was loaded over HTTPS, but requested an insecure image 'http://www.blesta.com/forums/uploads/profile/photo-thumb-11796.jpg'. This content should also be served over HTTPS.
index.php:2888 Mixed Content: The page at 'https://www.blesta.com/forums/index.php?/forum/17-the-lounge/' was loaded over HTTPS, but requested an insecure image 'http://www.blesta.com/forums/uploads/profile/photo-thumb-10467.jpg'. This content should also be served over HTTPS.
index.php:3189 Mixed Content: The page at 'https://www.blesta.com/forums/index.php?/forum/17-the-lounge/' was loaded over HTTPS, but requested an insecure image 'http://www.blesta.com/forums/uploads/profile/photo-thumb-10467.jpg'. This content should also be served over HTTPS.

The forums have been upgraded. One thing to note is that you need to log in with your Display Name. On the old version, it was possible to have a username that was different than your display name. If you are having trouble logging in, login with your name as it appeared when you posted.

Alright, got Gravatars turned back on. Fixed a couple custom avatars that were hard linking to http:// and causing SSL errors. If you find anyone whos avatar is breaking SSL, please PM me their username and I'll correct it.
So, what does everything think of the upgraded forums?

Just wondering if there is any dates or details of the next release thanks.

When user fills up the registration form, DirectAdmin module password part is visible:

Glad to see this finally go live.
 
We have been using it in production for the last 3-4 months (we were helping them squash bugs), it is a nice module!

Good news!!!, Blesta Module V2
 
I forgot to add one more information (Very important), Virtualizor ready for LXC: http://virtualizor.com/wiki/Install_LXC

I like it!
 
A few thoughts:
 
There should also be a setting in which clients who have no active services, open invoices or open tickets get moved automatically to 'inactive' after X days A limited client interface would be nice for clients with 'inactive' status, in case a client still wants to see payment, invoice, service or ticket history. This should be a per company setting, and is not a show stopper for me. At the very least, the login error should be different for clients with different statuses instead of it throwing a generic error. Other than that, I really like the feature in which new clients do not have full access until their order is approved. Definitely would help with fraudsters.

Can't there be an account dropdown on the top right once they're logged in? 
 
I.e : If you have 4 actual accounts, at the top right or wherever makes the most sense, you can an account dropdown and can select it there. That's how we managed permissions with designers who had access to multiple customer accounts at my previous company. 

Ah, that's right. Thank you for the clarification!