Redmine

+1

+1

+1

+1
We have small teams with specific areas of expertise. Being able to assign to a group, or a list of users is a must have.

+1
It will be very nice

+ 1 assign to group / multiple people

Eric Davis wrote:

(...) There are two things I'd like to get feedback on before committing this:

1. Should there be a setting to enable/disable assigning to a group?

As an outsider regarding use of the groups-feature of Redmine I'd say to implement it in a similar way to how it is done currently for the different "roles". Then the Redmine-admin is able to fine-tune which roles ánd groups should be able to get issues assigned to them himself.

2. Should the Assigned dropdown separate Users from Groups? Right now it will list users first and then groups but there is no separator.

For the sake of clarity I suggest to add some sort of seperator to at least be able to differentiate users and groups.

Eric Davis wrote:

1. Should there be a setting to enable/disable assigning to a group?

There should be some possibility to fine-tune this, as there are organizations or even projects where it would needed to be able to assign an issue to a group, and others where personal accountability is key and you won't want it, although being able to make groups to assign them to projects is desired.

On the other hand, I don't think this should be a role-level option, as the role you give a group gets propagated to all members, so the group doesn't really have a role of its own. Maybe a global switch to enable/disable group assignment, a project-level one, and maybe even for each tracker in a project would be the levels that come to mind.

The other difficulty I see here is that it's "difficult" to make a group, i.e. you need to be admin to be able to make groups. That will either result in people asking their admin to make groups for every other thing, or in people getting frustrated because they can't use the full functionality. I think redmine will have to go the extra step and allow issues to be assigned to multiple users (mass-assignment), be it through groups or whatever else, and that this ability be tied to the trackers (you might want features mass-assignable, but not bugs) and disableable on a tracker-in-the-project level (features are globally mass-assignable, but I don't want them to be for this particular project). That should then be tied to the ability for users to make their own groups which shouldn't be seeable by others (that would rapidly lead to a group overkill), the ability to assign an issue to multiple users without "actively" creating a group for that (think ad-hoc groups created only for one issue, which would retain the one-one relation between issue and user/group, but still enable issue mass-assignment without requiring to create a group beforehand), and still retain global groups (for which you could also configure if they should be available in mass-assignment or not, not sure having "accounting" with 45 people in the choices for whom you want an issue assigned to would be welcome…).

Mmh, I got a little over the scope of this issue in this last paragraph, maybe we could split that discussion in a new issue, as it would require a design decision at some point.

+1

Eric Davis wrote:

Should there be a setting to enable/disable assigning to a group?

It might be also beneficial to be able to assign "leader(s)" of a group at least to have possibility to only send notification about new issue only to this person(s), not to everybody from a group (as it is implemented in the patch now). Working members of Group should not be in some enviroments distracted by emails. We have managers to read-write emails :-)

Should the Assigned dropdown separate Users from Groups? Right now it will list users first and then groups but there is no separator.

Same dropdown, probably groups first, prefixed by @

I would love to use this! I'm on trunk (I know, I know), the patch doesn't apply cleanly to trunk. Could someone who's better at RoR update this? Pretty please?

+1
my think is a new role: allow/not to see that issues what is created by an user from other group.

Feature 2096 adds a custom "group list" field that could be used to emulate this to an extent. The patch has been updated to current trunk.

i add in redmine.rb the new privilege:

map.permission :view_issues_from_another_group, {:projects => :roadmap, 
                                  :issues => [:index, :changes, :show, :context_menu],
                                  :versions => [:show, :status_by],
                                  :queries => :index,
                                  :reports => :issue_report}

def visible?(usr=nil)
    s1=(usr || User.current).allowed_to?(:view_issues, self.project)
    s2=false
    s2=true if ((self.author.group_ids & User.current.group_ids).size)>0
    s3=User.current.allowed_to?(:view_issues_from_another_group, self.project)
    s1&&(s2||s3)
  end

+1

If I want to see all <<my>> tickets, I would also like to see
all ticket of groups I am in.

That is not the case right now, is it?

Or do I have to change some option I didn't see

Sorry, I'm a new to Redmine. How to apply this patch? I have tried the following:

C:\Program Files\BitNami Redmine Stack\git\bin>patch -p0 < C:\Software\0001-Allow-issues-to-be-assigned-to-a-Group.-2964.patch
can't find file to patch at input line 22
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 5d6addb9d8b7e66cb06730edaf64d7e004406800 Mon Sep 17 00:00:00 2001
|From: Eric Davis <edavis@littlestreamsoftware.com>
|Date: Mon, 28 Dec 2009 14:42:38 -0800
|Subject: [PATCH] Allow issues to be assigned to a Group.  (#2964)
|
|---
| app/controllers/issues_controller.rb      |    2 +-
| app/helpers/issues_helper.rb              |    4 ++--
| app/models/group.rb                       |    2 ++
| app/models/issue.rb                       |    8 ++++++--
| app/models/project.rb                     |    2 +-
| test/exemplars/group_exemplar.rb          |    9 +++++++++
| test/functional/issues_controller_test.rb |   29 ++++++++++++++++++++++++++---

| test/unit/issue_test.rb                   |   12 ++++++++++++
| 8 files changed, 59 insertions(+), 9 deletions(-)
| create mode 100644 test/exemplars/group_exemplar.rb
|
|diff --git a/app/controllers/issues_controller.rb b/app/controllers/issues_cont
roller.rb
|index 336f63b..2c3e08a 100644
|--- a/app/controllers/issues_controller.rb
|+++ b/app/controllers/issues_controller.rb
--------------------------
File to patch:

Anselm Hou wrote:

Sorry, I'm a new to Redmine. How to apply this patch? I have tried the following:
[...]

you have to use the patch command in the root redmine folder.
And try using -p1 instead -p0

Thanks for creating this patch. I just applied it and the patch seems to work fine. One feature I miss is the visiblity off issues assigned to groups. It would be nice if issues assiged to groups that I'm in are listed on "My page" under "Issues assigned to me" or better yet, listed in a new block called "Issues assigned to group".

Also, on the "vies all issues" overview page, groups are not listed in the "Assigned to" filter.

tks for that patch. Applied cleanly on 0.9.3 once I removed the test/exemplars/group_exemplar.rb bit.

# Should the Assigned dropdown separate Users from Groups? Right now it will list users first and then groups but there is no separator.

Also, a feature which could be nice is to assign to group by default, when I tried the patch, only users could be default assignee

Hi all, this useful patch doesn't work if you have Goyello redmine_mail_configurator plugin installed. Error 500 when you try to create a new issue assigned to a group.

|s

+1

I hope to see this feature soon in trunk.
Here's how we use group assignement at work:

A issue has an assignement group (e.g. SAP Support or Field Technicians) and the issue is then assigned to a member of that group.

Should the Assigned dropdown separate Users from Groups? Right now it will list users first and then groups but there is no separator.

Absolutely, then I can for example, assign to both a group (or multiple?) and a specific person within the group to lead it.

+1

I hope this gets committed soon

+1
This would be great as long as users can create/join their own groups.

If this is still relevant...

Should the Assigned dropdown separate Users from Groups? Right now it will list users first and then groups but there is no separator.

Yes, a horizontal line in the dropdown or writing "Users" before the users section and "Groups" before the groups section (gray these options out to prevent them from being selected) would work well enough.

If users would indeed be able to create their own groups, please make that an action you need a permission for. I would explicitly not like any user to be able to create a group, just project admins.

BTW.
included in 1.1?

+1

+1 on that and separate permissions for that capability.

Maybe it can be done by extending the category function, to have more than one resposible person - stakeholder.

I cannot install the patch in 1.01. Is this patch not compatible with 1.01?

Hi all,
Is there any reason that would explain why such feature has not been pushed in the tree yet ?

Basically I ask the same question Damien asks. Why is this feature not yet implemented in Redmine? Isn't this the type of basic feature any project management/ticket system should have? I would like to be able to assign issues to groups and I would like an overview page where I can view issues assigned to groups I'm in.

Hi,
I'm back on it as I just seen that Eric was planning this feature for 1.1.

Honestly, this is a must have feature for everyone using Redmine in a serious project. When the default assigned user is absent there is nobody to filter new issues which can be really bad when working in a company.

Please, could this be added in 1.0 branch instead ?

I would be happy to find this patch working under current version 1.0.1. When this could be possible?

Hi,
this issue has a status of 'assigned', but nobody is set as the assignee.

Could someone correct this please ?

I meant, could someone put status back to new as nobody is assigned ...

What should be the future of this feature?

I can't find it in any release plan.

I really need this feature! Can't really seem to understand how companies using scrum is able to use Redmine without this feature. Developers assign tasks to them selves, you don't want a project leader assigning tasks all the time. It should be enough that the team has been assigned a group of issues and then as developers get done with a task they can easily jump on to the next one that has been assigned to the group.
Pleeeaaase add this asap!

+1 We can use this feature.

Just added relations to #858 and #2809 (team support).

• manage teams or members for a project and its subprojects (name a team leader ?)
• assign issue categories to teams
• auto-assign issues to matching teams / team leader depending on category ?

Something like that.

+1 This is a must have for me as well.

Is there a plan to include this as part of the core system in a future release?

Hi!
The patch is not applicable anymore.
Could anybody adapt it to the current version of Redmine?
Thanks!

I also just tried to run this patch on Redmine v1.1.1 and received the following error:

patching file b/app/controllers/issues_controller.rb
Hunk #1 FAILED at 237.
1 out of 1 hunk FAILED -- saving rejects to file b/app/controllers/issues_controller.rb.rej
patching file b/app/helpers/issues_helper.rb
Hunk #1 FAILED at 82.
1 out of 1 hunk FAILED -- saving rejects to file b/app/helpers/issues_helper.rb.rej
patching file b/app/models/group.rb
Hunk #1 FAILED at 28.
1 out of 1 hunk FAILED -- saving rejects to file b/app/models/group.rb.rej
patching file b/app/models/issue.rb
Hunk #1 FAILED at 20.
Hunk #2 FAILED at 255.
2 out of 2 hunks FAILED -- saving rejects to file b/app/models/issue.rb.rej
patching file b/app/models/project.rb
Hunk #1 FAILED at 344.
1 out of 1 hunk FAILED -- saving rejects to file b/app/models/project.rb.rej

I would desperately love to have this functionality.

+1

I'm trying to migrate from eGroupWare and this feature is really missed :-(

+1

That feature would be very useful.

2 years ... hmmmm

happy birthday :-)

+1
This one was the first question after my redmine presentation in the company and i had to say "no it cant" :(

It is possible update this patch for the new Redmine version? Thanks

It would be really nice to have this feature for the next version. The bug sorting process in my company occurs in two steps: project leader first identifies the team a bug should be assigned to, assigns to it. Later, the team leader assigns the bug to one of his teammates. Currently we have to use unsatisfactory workarounds (duplicated users, sub-projects for a team...).

-1
Please don't add this feature to the redmine. Shared responsibility does not work.

Yeah and because in your opinion it doesn't work (for what you forgot to tell btw maybe for everything) this shouldn't be implemented.
In a lot of commercial systems features like this exist and in the company of my customer redmine lost the bet because it's missing. :(

It's still up to everybody to use or don't use such a feature. So why vote against it?

Should be configurable, switch on or off. Then its up to everyone howto handle it.

Michael Kling wrote:

Yeah and because in your opinion it doesn't work (for what you forgot to tell btw maybe for everything) this shouldn't be implemented.
In a lot of commercial systems features like this exist and in the company of my customer redmine lost the bet because it's missing. :(

It's still up to everybody to use or don't use such a feature. So why vote against it?

:-))

In the real life - in the real system - only you are responsible for your work. If more than one people has the same issue/task who are working on it? The other one....always.

When the work is done if more people are interested? What is the progress?

This "feature" that one issue has one responsible worker is the best tool to change your mind. If you have in mind that your company needs this feature, sorry, something should smells elsewhere ;o).

The easy workaround is add groups to dropdownlist with assignable people. When creating issue assigned to group, thus creating many of issues, how many people are in the group. But still exists one issue with one responsible worker.

Adding another checkbox somewhere to the administration is not the best solution (my opinion).

Regards

My customer don't need that feature for assigning the final responsible but as a step between.

He creates the ticket and assigns the group 'electro technicians', so all from this field (in the group) will have this ticket on the todo list until somebody takes it. (assign himself as responsible)

Because in their projects a lot of different fields are involved (programming, network and administration, electrical engineering, different kind of craftsman) and for all these fields they have a pool of people, they don't want to care about who is doing it just that somebody is doing it.

They are already working like this without redmine (via email lists) but now they want to organise it with a ticket system - without changing their working process.

(I wouldn't implement something like this either in my company but anyway it's what they want and I, as I like redmine very much, tried to give them this system as a solution)

I think "ur process" needs a coordinator, which handles tasks where there is no responsibilty. E.g Daily stand-up, where tasks with no "assigned to" person will be assigned. Thre must be a project leader or even team leader which will make sure thing get done, if u don't in worst case noone will catch an issue and it will be leaft unassigned forever. Assigning to a group is not even better than assigning to no one.
Your experts groups "programming, network and administration, electrical engineering, different kind of craftsman" doing compoents of the product, so just create categories for then with one "resposible team leader" per group, who will be assigned to the group. He gets email wehn project leader assign to category and must find someone in his team to be assigned to the issue at the end.

Just an idea.. to solve that in redmine now.

I think "u guys" need to lay off on the assumption that what works for you must work for everyone. If you don't want multiple assignment, don't use it. Like many commenters that went before me, RM was shot down in our company because this feature was not available.

I could turn the reasoning around and say that some companies have outgrown the strict command-and-control mindset that requires an issue to be assigned to any specific individual, and multiple assignment works just fine. We use it ourselves for our scrums, and it has never yet caused any problems. What happens if your coordinator falls ill or goes on a holiday? Everything gets reassigned? Everything stops?

I'm not saying you shouldn't use single assignment, but voting against multi-assignment as an optional feature is just dumb dogmatism.

Fri Flaj wrote:

I think "u guys" need to lay off on the assumption that what works for you must work for everyone. If you don't want multiple assignment, don't use it. Like many commenters that went before me, RM was shot down in our company because this feature was not available.

I could turn the reasoning around and say that some companies have outgrown the strict command-and-control mindset that requires an issue to be assigned to any specific individual, and multiple assignment works just fine. We use it ourselves for our scrums, and it has never yet caused any problems. What happens if your coordinator falls ill or goes on a holiday? Everything gets reassigned? Everything stops?

I'm not saying you shouldn't use single assignment, but voting against multi-assignment as an optional feature is just dumb dogmatism.

I gotta admit that I am big advocate of "1 issue = 1 person", but you really have a point here. Just don't use it and stay happy.

To stretch it further: a simple checkbox in administration "Allow issue assignment to Groups" could easily be added. Plus defining certain groups that cannot be assigned an issue to avoid trouble.

Count me among those who consider the lack of this ability to be a serious limitation. I understand why it would be a show-stopper issue for many organizations.

We have managed to work around this limitation by creating role-based dummy accounts tied to email distribution lists. While this does work, it's clumsy and arduous to maintain.

The ability to assign issues to roles and groups, as well as arbitrary combinations of project members would be extremely helpful.

Another question: say user A belongs to group G, should issues assigned to group G be listed when user A filters the issues with "Assigned to <<me>>"?

Jean-Philippe Lang wrote:

Another question: say user A belongs to group G, should issues assigned to group G be listed when user A filters the issues with "Assigned to <<me>>"?

My bet would go on "No", maybe separate and cumulable list items "<<only me>>" and "<<groups I belong to>>"?

Jean-Philippe Lang wrote:

Jan Wedekind wrote:

To stretch it further: a simple checkbox in administration "Allow issue assignment to Groups" could easily be added.

Agreed.

Well, if you configure assignable groups at project level, then you don't need this setting, do you ?

Feedback is welcome.

Looks like a very good idea.

Another question: say user A belongs to group G, should issues assigned to group G be listed when user A filters the issues with "Assigned to <<me>>"?

I revised my position : <<me>> should display issues assigned to groups I belong to, but still have no arguments :(

Etienne Massip wrote:

Well, if you configure assignable groups at project level, then you don't need this setting, do you ?

Actually, it will be usefull to adjust the UI for people who don't want to see anything about issue assignment to groups (see below). And choosing assignable users/groups at project level is a separate feature that may be added later.

I revised my position : <<me>> should display issues assigned to groups I belong to, but still have no arguments :(

I think it shouldn't. Because otherwise a user wouldn't be able to see the issues that are assigned to him and not to its groups.

A new option <<my groups>> could be added (and displayed only if group assignment is turned on). This way, we can choose <<me>> or <<me>>+<<my groups>> or just <<my groups>>.

Jean-Philippe Lang wrote:

I think it shouldn't. Because otherwise a user wouldn't be able to see the issues that are assigned to him and not to its groups.

From a assignee pov, I can't see the difference between being assigned directly or being assigned within a group, whatever the way, you're assigned and you're expecting the <<me>> entry to give you the issues you, personnally, will have to work on.

This may be true only if you don't consider this feature as a way to "pre-assign" issues, that is assign an issue to a group of which one chosen / random person will eventually be directly assigned to work on it.

Etienne Massip wrote:

This may be true only if you don't consider this feature as a way to "pre-assign" issues, that is assign an issue to a group of which one chosen / random person will eventually be directly assigned to work on it.

There are several comments here that show that some users expect to use this feature in this way.

Jean-Philippe Lang wrote:

The baheviour of assigned to <<me>> is unchanged for now.

If <<me>> does not include <<<my groups>>, users could easily miss issues assigned to their groups. If <<me>> includes their groups, one could still group by assignee or filter on their specific username to differentiate. I think the default <<me>> should include group assignments.

However, I'm concerned about the distinction between "Group" and "Role" in this context. At the project level, it is a member's Role membership that determines whether issues can be assigned to that user, and I think it makes sense to extend the issue assignment at the Role level rather than the Group level. Please also see #8891.

I didn't request that feature, but assigning issues dependent on role touches a feature request i made some time ago.
#8050 proposes to be able to set visibility, read-only or mandatory property of every field (also of assignee) dependent of the role a user has , who is editing the issue.
THis way the workflow can make sure that only certain roles are able to see or edit certain field values dependent on role an advanced even on the atcual issue status.
I think this disccussin in similar direction, doesn't it?

I have applied the patch, to my Redmine 1.2.0 , but it gives the following error when I try to create an issue, with
a group assigned to it.
"undefined method `active?' for #<ActiveRecord::Associations::BelongsToAssociation:0xb685a80c>".

Any ideas on which could be the cause?

William Baum wrote:

Issue assignment really needs to be based on Roles rather than Groups.

So we'll need to create bunch of roles and remanage everytime we need users in roles and set permissions to them? I always thought that roles mean security control functions rather than users management. "Groups" provide us ability to divide people to more concrete subparts of those who have access to the project duties based on "roles". From my point of view it will too complicated, but anyway it's better than nothing.

Could someone explain how to apply this patch to Redmine 1.2.
I really need assignment issues to group feature.

When i tried to apply with patch -p0 < /path/to/patch/0001-Allow-issues-to-be-assigned-to-a-Group.-2964.patch? - it failed:

patching file b/app/controllers/issues_controller.rb
Hunk #1 FAILED at 237.
1 out of 1 hunk FAILED -- saving rejects to file b/app/controllers/issues_controller.rb.rej
patching file b/app/helpers/issues_helper.rb
Hunk #1 FAILED at 82.
1 out of 1 hunk FAILED -- saving rejects to file b/app/helpers/issues_helper.rb.rej
patching file b/app/models/group.rb
Hunk #1 FAILED at 28.
1 out of 1 hunk FAILED -- saving rejects to file b/app/models/group.rb.rej
patching file b/app/models/issue.rb
Hunk #1 FAILED at 20.
Hunk #2 FAILED at 255.
2 out of 2 hunks FAILED -- saving rejects to file b/app/models/issue.rb.rej
patching file b/app/models/project.rb
Hunk #1 FAILED at 344.
1 out of 1 hunk FAILED -- saving rejects to file b/app/models/project.rb.rej
patching file b/test/exemplars/group_exemplar.rb
patching file b/test/functional/issues_controller_test.rb
Hunk #1 FAILED at 532.
Hunk #2 FAILED at 933.
2 out of 2 hunks FAILED -- saving rejects to file b/test/functional/issues_controller_test.rb.rej
patching file b/test/unit/issue_test.rb
Hunk #1 FAILED at 27.
Hunk #2 FAILED at 362.
2 out of 2 hunks FAILED -- saving rejects to file b/test/unit/issue_test.rb.rej

I've tried to modify code manually, but some files contents is differ with that one in patch.

Is there any new version of this patch that compatible with Redmine 1.2?

Is it possible include tasks in filter results for users assigned groups?
E.g. user User1 included in group Grp1. When make filter by User1 I see tasks assigned on User1 but don't see tasks assigned on Grp1.

+1

Do not post to closed issue.

Toshi MARUYAMA wrote:

Do not post to closed issue.

I think there is a feature request for this.