Defect #9132

Filtering by "Assignee's Group" doesn't show issues assigned to the group

Added by Ariel Scarpinelli over 6 years ago. Updated almost 5 years ago.

Status:ClosedStart date:2011-08-26
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:Fixed Affected version:1.3.0

Description

To Reproduce:
- Create a new issue assigned to a group
- go to issues list, filter by "assignee's group" and choose the same group that you assigned to issue to

Issue:
- The recently created issue does not appear

Expected behavior:
- The issue should appear, as the "group of a group" should be the same group.


Related issues

Related to Redmine - Feature #5869: Issue filters by Group and Role Closed 2010-07-11
Related to Redmine - Feature #2964: Ability to assign issues to groups Closed 2009-03-13
Related to Redmine - Feature #7867: Author group filtering Reopened 2011-03-15
Related to Redmine - Defect #13006: Filter "Assignee's group" doesn't work with group assignm... Closed

History

#1 Updated by Etienne Massip over 6 years ago

  • Category set to Issues

#2 Updated by Etienne Massip over 6 years ago

Ariel Scarpinelli wrote:

(...) the "group of a group" should be the same group.

Not sure. If some day RM handles groups as an organization tree, this won't be true anymore.

#3 Updated by Etienne Massip over 6 years ago

Etienne Massip wrote:

Not sure. If some day RM handle groups as an organization tree, this won't be true anymore.

And I'm not sure it's true as it is for now: the real thing is that your group does not belong to another group.

#4 Updated by Ariel Scarpinelli over 6 years ago

Ok, first of all I will rephrase myself:

the "group of a group" should be AT LEAST the same group. That means: if a the group is used as a user (i.e. an issue is assigned to the group), then the group should be considered as user that belongs to that same group. It has nothing to do with the fact that later on you could build a tree of groups.

Now I will try to expose the actual use case:

In our organization we have many projects. Those projects have issues that should be executed by people of different teams in a cross-project manner (for instance, all our projects require many tasks from the Graphic Design group, but with many gaps between them in time, so no designer is assigned full time to a project).

Some of these issues could be directly assigned to a certain person (for example if the person had worked on the same project before) and some others could be assigned directly to the group, waiting for someone to pick them up. This last option goes well with the idea implemented by RM that "issues assigned to me" shows both issues assigned directly to me, and the issues assigned to my group. This allows the group to have a work queue where anyone can take a particular task when becomes free.

As the manager of the group, I need to be able to list all the open issues for my group. I implemented this by simply filtering for "assignee's group equal my group", but this later query only shows me the issues actually assigned to people, not the issues assigned to the group "as a user".

One quick and dirty fix is just to create a fake user that belongs to the group and assign all the "unassigned" issues for the group to that user, however this breaks the work queue model by requiring the people look at a different place than "issues assigned to me" when they run off issues assigned to them.

I believe that the fix should be very easy to implement.

Please let me know if I made myself understand or you require any further info.

#5 Updated by Etienne Massip over 6 years ago

Ariel Scarpinelli wrote:

the "group of a group" should be AT LEAST the same group. That means: if a the group is used as a user (i.e. an issue is assigned to the group), then the group should be considered as user that belongs to that same group. It has nothing to do with the fact that later on you could build a tree of groups.

I understand, but disagree.

I understand your case, and I think that a correct fix would be to have a query with a logical disjunction of both criterias:
  • Assignee's group IS "GROUP1"
    OR
  • Assignee IS "GROUP1"

Which is admittedly not possible right now with Redmine.

#6 Updated by Ming-Chin Chen almost 6 years ago

I do agreed with Ariel Scarpinelli.

A group is a dummy user in user table, if a ticket assigned to this group, it should be listed by criteria specified as Assignee's group equal to this group.

#7 Updated by Ariel Scarpinelli almost 6 years ago

Etienne Massip wrote:

  • Assignee's group IS "GROUP1"
    OR
  • Assignee IS "GROUP1"

Which is admittedly not possible right now with Redmine.

I do agree that redmine needs OR queries, but that is far more complicated to implement than my request.

To avoid any semantic discussions, why don't we just create a new filter, or rename the existing one from "Assignee's group" to simply "Group". That way we create a new field for the issue which is group, and its value is either the assignee's group if the assignee is a user, or directly the group the issue is assigned to.

#8 Updated by Toshi MARUYAMA almost 5 years ago

  • Affected version (unused) changed from devel to 1.3.0
  • Affected version set to 1.3.0

#9 Updated by Toshi MARUYAMA almost 5 years ago

Is this issue fixed by #13006 r11285 ?

#10 Updated by Jean-Philippe Lang almost 5 years ago

  • Status changed from New to Closed
  • Resolution set to Fixed

Toshi MARUYAMA wrote:

Is this issue fixed by #13006 r11285 ?

Yes. Strictly speaking, a group does not belong to a group indeed but it really makes sense to filter issues assigned to a group when filtering by "Assignee's group".

Also available in: Atom PDF