|
History
| Log In
|
|
|
|
I would like to request this as well. I installed 3.7 and setup all my users using project roles before I realized I couldn't filter Assignee = Project Role or share filters by project role. Now I'm back to groups
Agreed, this greatly undermines the great Project Role feature and in fact makes it worse... to handle filters in a Project Role environment, you now have to manage both (unless you revert back to using groups exclusively).
I do not think we will be able to implement this in the bug fix branch for 3.7.
This is only one of the drawbacks of using roles, but indeed, a very bad one, hope this gets fixed soon. One way or another, a role associated with a project should result automatically in some sort of a dynamic group. This together with the possibility to share filters to multiple groups, or create filters created by one of the members of multiple groups would make user management a lot easier.
My concerns have been voiced above. I would like to be able to share filters to specific Project Roles.
As I share filters on a per project basis this is definitely something I need. Using project roles makes life easier in many respects but being forced to use groups for filtering does not.
So my vote My vote also
 .I asked for the same feature in JIRA support and was forwarded to here. We very need this feature especially as we want to create filters for our customers and wouldn't like to share with them filters from other projects. So dear Atlassian please complete "Fix Version/s:" field.  It was very frusterating to get all the Roles working on all my 100 plus projects and then find that I still need to manage a Group for Filtering. JIRA you need to fix this issue so that admins do not have to manually update a Group for each project when people want to share filters.
I see a couple of solutions to this. 1. Allow the Administrator Role to also administrate a Group that has been assigned to their project. The main point for me, is to elimenate the need for the Admin to have to manage 400 plus engineers and testers in sharing filters. Move that responsibility to the Administratior Role and let the Administrator manage this. In my mind this is a huge bug in the Role based scenario and needs to be fixed ASAP. Hi,
oh, I'm really glad that I've seen this issue before changing everthing to roles. After long discussion we just decided to switch to roles, because we're not really happy with the fact that with roles the project admins can do user management. But anyhow we found a way to prevent that. And I also can't tell my users now that sharing filters doesn't work anymore. A feature that is familiar and used is difficult to argue why it's not available anymore. And therefore I argree with the comments before mine - this is really a bug in the feature project role and needs to be fixed. Cheers, I had converted all our projects to use roles instead of groups, then happened upon this issue. Good thing!
I was about to delete all of our groups. What a mess that would have been! All the filters associated with a group would have broke, and that would have led to a lot of unhappy campers here. Now I'm going to have to figure out how to sync the groups with the roles, because since converting everything over to roles, I'm sure these groups have gotten a bit stale and are no longer accurate. I would agree that this is really a bug and not a feature request. Major oversight if you ask me. Honestly, now I'm regretting converting everything over to roles. What a frakking mess. C'mon, Atlassian. This stuff makes project roles lame! As mentioned above, the clear solution is to consider a 'project role to project' association to be a dynamic group. So if I have a project role named "Team Members" and a project named "HR", everywhere Jira uses a group I should be able to pick "Proj Role: HR: Team Members" from the group list if I have Browse permission on the project.
There's a workaround for this. Make a group containing all the people in the particular role. Share the filter with the group, and associate the group with the role. So project A's developer role is defined as the group "A-developers" and that's the same group that the filter is shared with. Maybe a little extra work, but you have groups for each of your roles, right? It's either that or manually adding individual users to project roles, which sounds inefficient to me.
Daniel,
That workaround sounds great in theory, but you just ruined the whole point in the Roles to begni with. On a Jira server with 200-400 projects, removing the extra groups and permission schemes is the first step in improving performance. Reality is, with out having the ability to share filters or "other group", users will be forced to have the Jira admin's create a group for them. They then need someone to put the users into that group and then make sure the group is browsable to the project (through a read-only role perhaps). What you have just done, is removed the use of the Role. The ability for projects to be self-managed. With out this support from the vendor, more people are going to look at setting up XML-RPC based mangement pages. Good point. I hadn't considered that roles are configurable by project admins, but groups require a full admin.
David has hit on the crux of the issue here. Full admins like myself do not want to have to manage groups for the 200 plug projects that we are running. The roles allow us to off load project management to the Project or Product leads and if the sharing of filters were role based then we (admin) would not need to be involved with having to set up groups for each project. It would all to the administrator of the roles to do this thus saving time and resources for other more important admin work.
Hi,
We are trying to get this done for JIRA 4.0. Cheers, |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Filter sharing does not currently allow you to share with a role. 
I sure hope folks take seriously the request to allow sharing/subscription by project roles. Now we've got to maintain both roles and groups, and even worse, the groups aren't available via LDAP the way they can be with Confluence, so even more headache and support overhead.
And while you are at it... muliple groups