Assignee list should render assignable users based -if exists- on (Issue Security Level)

[wajdhaikal]

I think the current behaviuor of the assignee list in JIRA has a logical bug. whats the purpose of letting the current user assigned to issue and has assigne permission toi assigne this issue to people who can not ever see the issue beause of the issue security level.

Our managment is angry about this in JIRA and blaming me for this behaviour and they are requesting any solution by development or by any way to only let the issue be assigned to the proper person in the team and not all assignable users should be available to select from , and this is logical as every body says!!! Why can not JIRA do this while some other tracking systems do.

[wajdhaikal]

I Have achieved the goal via some new conecpts developed in addition to using all (Components, Project Specific Roles and Security Levels enabled) this solution is special to certain requirments in our copmany.

[Nic Brough -Adaptavist-]

That's the point - it already does provide team/assignee lists - you can do it by role, group or even field. Your question was about doing it by security level, which is convoluted and not really anything to do with teams.

Issue security is about hiding issues from users, not determining who can be assigned to it, especially, as Dieter points out, you can break the setup by changing the security level. You're trying to derive an assignee list from two places, one of which really isn't designed for it. I think you need to look more closely at what you can put into the assignee permission - play with the group-custom-field value for example.

[wajdhaikal]

no, here the proper customization plays its role; there is one person that exists in all roles who is only able to set the security level and edit the issue. but I think JIRA should provide team concepts soon in addition to the current nice features. for now I'm still thninkng to do some behaviour change soon for JIRA assignee list without affecting other projects and dependency but needs sometime.

[Dieter]

Even if you had such an improved user picker think of the case someone decides to set a security level on the issue later that prevents the assignee from seeing it. Ask your management what should happen then ...

[wajdhaikal]

:) forget about our management , yes requires some coding and handling, but a proper solution should fit at the end

[Nic Brough -Adaptavist-]

...and now you've hit one of the reasons for not hiding issues from users. Frankly, this is about education - your users should KNOW who is assignable, what they're asking for is a masssive amount of hand-holding because they don't want to actually think or understand their own procedures. Yes, this is alittle bit of a hole in the implementation of assignee, but if you did remove "people who can't see the issue", there's actually a lot of coding and work to do, and I can guarantee you end up with "I need to assign it to person Y and he's not on the list, fix it now"...

Personally, I'd code up a new user picker, one that works off security level, then copy the assignee selected in there using a listener.

[Radu Dumitriu]

If you feel this is a bug, please report it.

Normally, I wouldn't refuse a development request, but what if your management will get angry on me and I will not get paid ? mmmm....

[wajdhaikal]

I need somebody to prgram this and i will pay him.