John

I am aware that Blesta has a Newsfeed to let us know about the different patches they have released.
BUT...
The issue is that the news can easily be missed unless we are actively monitoring for it.
=============
PLEASE consider adding a 2nd option within your newsletter sign-up where we can receive email alerts for the  Blesta Patch Updates
 
Look forward to your reply.

Try this
$packages = $this->ArrayHelper->numericToKey($this->Packages->getAll($this->company_id, array('name' => "ASC")), "id", "name");  

Wow I'm an idiot. Obviously my searching skills are not up to par tonight.
Thanks Mike.

This is a great idea that I'd love to see implemented. Anything to further security is good in my opinion, as long as we try to make it as painless as possible.

Blesta version 4.0.0-b2 (BETA 2) is now available. You can download it from right here (Client Area Login Required).
If you haven't seen the blog post announcement for 4.0.0 BETA 1, you can read it here.
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 and b2. SEE BETA2 ONLY

For older releases see all Change Logs.
What to Test!
1. New The SSL Store Module and Plugin. Please test the module and plugin. The module allows you to automatically create a package for all of The SSL Store's SSL products. When doing this, please create a new Package Group first, and select this as the Packages will be placed in this group automatically. If you don't have an account with The SSL Store, create one here.
2. Void unpaid invoices when cancelling a service
3. Multicraft, which contains 2 fixes. Plus misc. other bugfixes from beta1. See the changelog.
4. Test everything! Version 4 is a major release.

I wish this was possible in v3 but sadly it isn't but Paul said it is coming in v4 though.

First . We never change password to a password that client want . We change the passwords to a generated one and send email about the new password .
The client can request password change but can't determinate it via ticket .
Also is good to see a lebel about how this ticket was opened (manager, email piped,  import email, Api ... )

With Blesta (and most other ticket systems), you can create a ticket by sending an email to the email address associated with the account. While this is a very nice convenience for clients, it also poses a security risk.
Say I am trying to attack David Smith (david@smith.com), and I know he hosts with 'XHost'. All I need to do is find the support email for 'XHost' and spoof an email coming from david@smith.com saying something like this:
Now, I just have to keep trying the password I asked for, and soon it will be changed.
The best way to prevent this is to have an indication on each reply to say if it came in via email or the client area. That way the host could take extra precautions, like asking for a reply via the client area before sensitive actions are taken.
 
Another thought would to have a "BoxTrapper" type system, where if you open a ticket via email, the system sends you a link to click on, and it would then mark the ticket safe.

not sure, but i think this can be done in language files .
 

Some people will consider the confirmation link an unnecessary hassle for the vast majority of ticket requests. However, I do think showing the method by which the ticket was created would be useful in helping staff determine how to proceed. The link would need to be a setting, and is more complicated to implement, so I'm thinking mainly shorter term.
Sound good? Any suggestions of where we would want to show how the ticket was opened?

But what are the usernames?

Very much agree with this.
How we dealt with this in another system was this way : 
- If a user opens a ticket from their client portal, and 2 factor is enabled : perform the request
- If a user opens a ticket from the client portal, but 2FA is not enabled : ask for a support pin or security question
- If a user emails in : same as above
The support pin or security question is something the user sets up at order time. They cannot be changed or reset by the customer. If they need to be reset, you ask for ID before allowing the user to change them. 
And then of course, it was noted on the ticket how it was opened, as suggested in this thread. 

Yes, I came across this because I am trying to customise Blesta for a special purpose. Otherwise I wouldn't have noticed this. This will not be when you create few customers. But a huge issue when several staff members are allowed to create clients. There is a possibility someone may create, by mistake,  a client with a duplicate email address. I am just checking all possible loopholes and I want to rectify them before using Blesta on production.

Don't know about front end registrations. I am trying to customise this app for Admin creating clients and issuing invoices. This way the client gets an invitation email. I have not sent any email msgs yet because I am only simulating these issues on a localhost. But again, when you do create clients through Admin panel then the first client gets the wrong mail even if the second client is supposed to receive the invitation e-mail. This happens only if the admin panel creates clients. I have not tested the front end regs yet.

Not a bad idea for the link to click on. so they have to login and then a label shows up saying "secure"

Yeah, or maybe the reply is red and says "unsecure" until they click the link. That way not every reply needs to be marked secure, but only the unsecure replies are marked as such.

There are many reasons why a system (client portal in the case of Blesta) should have a UNIQUE email address.
One simple reason is "When one recovers the password".  This is a security measure. An Admin ( or Staff ) may by mistake duplicate email addresses while creating clients. To avoid this the email address should be unique.
There are several other reasons too.
*********************
In fact I was not checking this email address thing purposely. I came across this accidently while trying checking functions of various other inputs in order to develop a plugin for a particular project. But this finding is unexpected.

How to prevent this? i got this problem too.
My clients create 2 accounts with same email. And how to force user, to only use email as login. Not username.
like @naja7host (blesta-addons registration page)?

Hi Dev Team,
Since I am new to Blesta I started testing the v3.6.2 for two reasons. 1) I wanted to get it customized for our business 2) Check bugs/security if any. I started testing Blesta on a localhost (laptop) with a trial license.
To my surprise I found that two clients can be created from Blesta Admin Panel with the same (identical) email address. I tested this with client's other data different from one another but the email address. This is not acceptable.
It should NOT be like that. Can someone from Dev Team explain this to me?
Thank you in advance.
 
P.S. I can check this myself. Would appreciate if Dev can pm me the names of the files related to Admin Creating a Client, as I am busy at the mom and don't have time to study all coding in Blesta. Thanks again.

Understood, I know how gravatar works. However, I am trying to find what email the 'system' user uses. (For ticket auto-closed emails)

I tried to log in to the admin area, and it appears the license key is invalid.

Working now. Must have been cached for me.

We went with a click menu instead of hover because mobile devices can't hover. Once you click, you can hover over other primary nav items and view the subnav without clicking again. So, we tried to make this work in the most intuitive way. Appreciate your feedback, and curious what others think of the menu as well.  

Works for me: http://screencast.com/t/5D2CLULeirZX

When you don't have permission to view the System settings tab, you don't see an error, so I suggest that maybe it's removed or disabled fully when you don't have permission?
So from:

To: