Redmine

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.

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.

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.

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.

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

Which is admittedly not possible right now with Redmine.

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.

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.

Is this issue fixed by #13006 r11285 ?