|
I think this could be implemented as a custom field now.
What's going on with this issue?
Is there a chance to have it with version 3.2? At least it doesn't look that hard to implement and it would be really really useful. We are using security levels to control customer access, and a filter on this would help us view the issues by customer.
Just to put in my oar here... I'm trying to do the same thing as Sulka Haro, so could use this feature.
Cheers. Just would liek to mention that it is possible to add the Security Level to your Navigator Columns list and tehn sort the results by it. I know this is not the best solution.
Sorry Mark,
3.3 is due out any day now and no new features will be added to it. I am guessing 3.4 dev is starting on Monday. Though keep in mind we concentrate on the most popular features for releases: http://jira.atlassian.com/browse/JRA?report=com.atlassian.jira.plugin.system.project:popularissues-panel 3.4 has already been scoped and this change is not in but we will consider it for the next release. Cheers, Four more votes and this issue will be in popular issue list too
Now it is in the popular issue list!
Hi!
I'm on my vacation and will be back at the office on July 30th, 2006. If you got this email after sending a message to an email list I've subscribed to, please accept my apologies on behalf of the autoresponse-system. Thank you, sulka Jeff - why is the component Custom Fields? Security Level is a standard field, isn't it?
should be "Filtering & Indexing"
Yes, "filtering and indexing" is better. It could be implemented as a new custom field type, hence the component.
This is a sorely needed feature. We use security levels to tag issues for review by our security working group, and we really have no good way to see the whole range of security issues at a glance.
I also use Security Levels for tagging issues to customers. It would be very helpful to have this functionality.
I agree. But make it also possible to filter with and/or (in secgroup x and secgroup or secgroup z)
When will this feature be available? I realy need this.
We would also like to havbe this function. The number of Sub-Projekts is growing fast and the number of user groups with various security levels is increasing. Therefore this filter would ease work quite a bit.
Gruss, Lukas For us this functionality is also very important. We already have 72 votes and the implementation should not be too complicated, should it?
Dear Atlassian Team, for what future release are you going to consider the change? The issue is still unassigned... HI,
As a workaround I have published this plugin: http://confluence.atlassian.com/display/JIRAEXT/ILOG+Security+Level+Searcher+Plugin Cheers Any update on this functionality being built in.
I haven't tried the plug-in yet, but I shouldn't have to, at least not for security related features. It's hard enough to keep up with the rapid jira releases as it is (if you fall too far behind, it's a nightmare), and then to test all the plugins for compatibility and functionality. This feature was requested back in version 2.5.3.... 3.11 is out... over 40 releases and this hasn't been addressed yet? I'm going to try out the plug-in, but once again... I shouldn't have to. -Dom Hi there,
We are interested in this issue as well because we use the "Security Type" in some Jira-Projects to map the different kind of contracts we have with the customer. These contracts are security relevant. eg. Technical People of a customer should not see their business-issues but the technical issues. Just some personal thoughts: Thanks a lot to Pierrick for the plug-in. I've installed it and it seems to work OK even if one can not select one of the Security Levels but need to type in its name (or part of it). This is a little tricky to explain to the regular user but is better than not having this functionality. Cheers, Marc We are using the security level to maintain a knowledgebase (published = customers, published internal = technical sales, etc.). We're unable to define filters and thus, no chance to know what issues need work or need to be revised after each release. This is getting more and more time consuming as the sheer number of issues increases.
I'll ask our IT to have a look at Pierrick's plugin... thanks for the pointer. I find it disturbing that core issues like this one go ignored for, quite literally, years while many people continue to request it. While I appreciate Pierrick's plugin, it needs more features. Thank god it works in 3.12 or I'd be shrugging at our developers here.
What does it take to bump missing features up the list, a mass of votes and watchers? This and the subtask missing security issue should both be fixed prior to 4.0 which is probably years away. We are looking to use this too. We're running JIRA 3.12.3 Enterprise with a Commercial license.
We are also looking for this feature. I need to make some bulk changes on filtered issues by security level. And also waiting for some years ...
This missing feature makes it very hard for us to manage issues of several large customers. I can not believe that this has not been adressed for 4 years now.
If plug-in written by Pierrick doesn't solve this for you, you can try JIRA Client of ours (not free). It can search and show distribution by Security Level.
My apologies for the shameless commercial. We have essentially a "public housing" project whereby we provide users around the company a quick and generic issue tracking project (as an interim solution until we can build a custom one). To do this, we separate them using security levels. Some users have more than one affiliation (i.e., Security Level) so they want to be able to filter by Security Level.
Add my vote to the list. I'm working on an EC project and filtering issues on the "Security Level" would have been very usefull.
Filtering by security level is also very important for us. We need to be able to quickly sort whether a particular bug is known or reported by the customer or whether it's an internal only issue.
I've voted for this to be sorted too. Same as lots of folks here – we use security level to represent customer and allow access by customer. Ridiculous that we pay for maintenance and then use a freebie plugin.
Nice one on the fix version Atlassian - this will be very useful!
Wow, we bought JIRA a couple of weeks ago and very soon we ran into this limitation. It's hard to believe this issue has been open for 5 years.
Does anyone know if the plugin works on 3.13.2?? One workaround, of sorts, that I used is to correlate components with security levels. Every security level = a component. This allows my users to search by component, therefore security level.
Obviously, this limits the use of components and if you need to define multiple components for eac security level it won't work. I can't imagine why it would be hard to add the SL field to the search criteria. It sounds like it might be just limited resources rather than technical limits??? i can not understand that this issue is still unassigned.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Any chance of seeing this any time soon?