It would be valuable to allow more than one Issue Security Level. This would reduce the need for multiple levels to match the different combinations of Roles.
For example, my company would like to create a Infrastructure Upgrades project. This project will involve many outside consultants and internal staff. I can use roles for permissions, and I can create the following issue security levels based on the roles we have - a sampling could be
Omniware Internal
Sales
Network Admin
External Gui
External Web Services
External Developers
This allows me to create issues for Sales people only that NetworkAdmins can not view.
If I want to assign an issue that both the Sales and Network Admin roles can see (e.g. a task relating to a product install at a client site), I would then need to create another security level for Sales_and_Network.
So, if I have 5 levels representing 5 types of 'employees/security levels', I need to create 5 factorial (120!) levels to allow for all the different combinations.
Instead, I would prefer to simply select multiple security levels for an issue, i.e. "Allow the Sales and Network Admin levels to view this issue"
Improvement
Open
Major
Allow multiple Issue Security levels to be selected
I see what you mean. May I ask how often you need an issue to be protected by a security level and needs to be shared between all these groups? Do you need to cover all 120 combinations, or is it possible to work out a subset that you need most often and create the appropriate security levels for this subset?
Another way to approach this would be to create a Multi-Group custom field and then change the Permission Scheme to be based on the custom field. This way issues can start off as being protected, but you can then add extra groups to the custom field, and allow the members of these groups to see the issues.
The reason I ask, is that we find that in most situations a single value security level covers most of our customers' needs. Allowing to select multiple values also makes JIRA slightly more complicated. JIRA is quite flexible already, and we need to be carefully watch out for anything that makes JIRA more difficult to learn.
Would the above suggestions help?
Cheers,
Anton