Feature #2964
closedAbility to assign issues to groups
50%
Description
It would be a nice feature to add, since there are plans for upgrading groups in 0.9, so that tasks can be assigned to entire groups, groups of people, or a select number of people.
It could be done via a listbox element.
This could be useful in a situation where there are multiple departments to a company or multiple people who can or will work on said task.
Thank you
Files
Related issues
Updated by Steve Diver over 15 years ago
+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.
Updated by Eric Davis over 14 years ago
- Category set to Issues
- Assignee set to Eric Davis
- Target version set to 1.0.0 (RC)
+1 This would be useful for general tasks that should be handled by "someone in the X department". It could also provide a solution for #408.
Updated by Eric Davis over 14 years ago
- File 0001-Allow-issues-to-be-assigned-to-a-Group.-2964.patch 0001-Allow-issues-to-be-assigned-to-a-Group.-2964.patch added
- Subject changed from Ability to assign tasks to groups to Ability to assign issues to groups
- Status changed from New to 7
Here's a patch to allow issues to be assigned to groups. There are two things I'd like to get feedback on before committing this:
- Should there be a setting to enable/disable assigning to a group?
- Should the Assigned dropdown separate Users from Groups? Right now it will list users first and then groups but there is no separator.
Updated by Mischa The Evil over 14 years ago
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.
Updated by Felix Schäfer over 14 years ago
Eric Davis wrote:
- 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.
Updated by Anonymous over 14 years ago
+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 @
Updated by Fri Flaj over 14 years ago
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?
Updated by Szabolcs Klement over 14 years ago
+1
my think is a new role: allow/not to see that issues what is created by an user from other group.
Updated by Fri Flaj over 14 years ago
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.
Updated by Szabolcs Klement over 14 years ago
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}
in models/issue.rb change the visible? proc:
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
Updated by Daniel Maas over 14 years ago
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
Updated by Anselm Hou over 14 years ago
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:
Updated by Alessio Franceschelli over 14 years ago
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
Updated by Wytze Keuning over 14 years ago
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".
Updated by Wytze Keuning over 14 years ago
Also, on the "vies all issues" overview page, groups are not listed in the "Assigned to" filter.
Updated by chantra . over 14 years ago
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.
I would say it can be handy to visually separate groups from users. I would find it easier to find where the groups are hidden within the list, but that might be just me :)
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
Updated by strexy strexy over 14 years ago
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
Updated by Daniel Nautré over 14 years ago
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.
Updated by Tyler Mulligan about 14 years ago
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
Updated by Eric Davis about 14 years ago
- Target version deleted (
1.0.0 (RC))
This patch is going to need some reworked and missed the feature freeze deadline. If we can get it updated, I think it can be included in the 1.1 release.
Updated by Jesse Mayes about 14 years ago
+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.
Updated by Fri Flaj about 14 years ago
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.
Updated by Paul paul almost 14 years ago
+1 on that and separate permissions for that capability.
Updated by Terence Mill almost 14 years ago
Maybe it can be done by extending the category function, to have more than one resposible person - stakeholder.
Updated by ardel biscaro almost 14 years ago
I cannot install the patch in 1.01. Is this patch not compatible with 1.01?
Updated by Damien Couderc almost 14 years ago
Hi all,
Is there any reason that would explain why such feature has not been pushed in the tree yet ?
Updated by Wytze Keuning almost 14 years ago
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.
Updated by Damien Couderc almost 14 years ago
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 ?
Updated by Przemyslaw Jacko over 13 years ago
I would be happy to find this patch working under current version 1.0.1. When this could be possible?
Updated by Damien Couderc over 13 years ago
Hi,
this issue has a status of 'assigned', but nobody is set as the assignee.
Could someone correct this please ?
Updated by Damien Couderc over 13 years ago
I meant, could someone put status back to new as nobody is assigned ...
Updated by Val Budkin over 13 years ago
What should be the future of this feature?
I can't find it in any release plan.
Updated by Nicklas Westerholm over 13 years ago
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!
Updated by Etienne Massip over 13 years ago
Updated by Chris Darts over 13 years ago
+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?
Updated by Vlad Shchiptcov over 13 years ago
Hi!
The patch is not applicable anymore.
Could anybody adapt it to the current version of Redmine?
Thanks!
Updated by Chris Darts over 13 years ago
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.
Updated by Pedro Almeida over 13 years ago
+1
I'm trying to migrate from eGroupWare and this feature is really missed :-(
Updated by Michael Kling about 13 years ago
+1
This one was the first question after my redmine presentation in the company and i had to say "no it cant" :(
Updated by Luis Serrano Aranda about 13 years ago
It is possible update this patch for the new Redmine version? Thanks
Updated by Had Mine about 13 years ago
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...).
Updated by Petr Pospisil about 13 years ago
-1
Please don't add this feature to the redmine. Shared responsibility does not work.
Updated by Michael Kling about 13 years ago
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?
Updated by Terence Mill about 13 years ago
Should be configurable, switch on or off. Then its up to everyone howto handle it.
Updated by Petr Pospisil about 13 years ago
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
Updated by Michael Kling about 13 years ago
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)
Updated by Terence Mill about 13 years ago
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.
Updated by Fri Flaj about 13 years ago
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.
Updated by Anonymous about 13 years ago
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.
Updated by William Baum about 13 years ago
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.
Updated by Jean-Philippe Lang about 13 years ago
- File members_tab.png members_tab.png added
- Assignee set to Jean-Philippe Lang
- Target version set to 1.3.0
This feature will be added to 1.3.0.
Jan Wedekind wrote:
To stretch it further: a simple checkbox in administration "Allow issue assignment to Groups" could easily be added.
Agreed.
Plus defining certain groups that cannot be assigned an issue to avoid trouble.
An even more flexible way would be to offer this option at project level. A simple checkbox in front of each project member (user or group) that can be updated by project managers:
Feedback is welcome.
Updated by Jean-Philippe Lang about 13 years ago
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>>"?
Updated by Etienne Massip about 13 years ago
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>>"?
Updated by Etienne Massip about 13 years ago
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 :(
Updated by Jean-Philippe Lang about 13 years ago
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>>.
Updated by Etienne Massip about 13 years ago
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.
Updated by Jean-Philippe Lang about 13 years ago
- % Done changed from 0 to 80
Feature committed in r6306. The baheviour of assigned to <<me>> is unchanged for now. I'd really like to get some feedback from people who requested this feature.
Updated by Jean-Philippe Lang about 13 years ago
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.
Updated by William Baum about 13 years ago
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.
Updated by Terence Mill about 13 years ago
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?
Updated by Jean-Philippe Lang about 13 years ago
- Status changed from 7 to Closed
- % Done changed from 80 to 100
- Resolution set to Fixed
Updated by Tudor Cornea about 13 years ago
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?
Updated by William Baum almost 13 years ago
- Status changed from Closed to Reopened
- % Done changed from 100 to 50
Issue assignment really needs to be based on Roles rather than Groups.
Assigning issues to Roles makes perfect sense, as evidenced by the "Issues can be assigned to this role?" permission. Yes, please, I would very much like to be able to assign issues to this role. Why can't I?
There is correctly no "Issues can be assigned to this group" checkbox, just as there is no "Issues can be assigned to this User" checkbox on the User profile page, because issue assignment is Project Role thing, not a User/Group thing.
The way this is implemented in r6306, the Group must also be assigned to a Role that can have issues assigned to it, so why not just allow assignment to the Role itself? The extra step up to Groups simply reduces flexibility and functionality.
Also, now that issues can be assigned to more than one user, why not allow a multi-select expansion for issue assignment?
Updated by Anton Lukashev almost 13 years ago
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.
Updated by Danil Shein over 12 years ago
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?
Updated by Jean-Philippe Lang over 12 years ago
- Status changed from Reopened to Closed
Please open another ticket for role assignment. This won't be part of this one for 1.3.0.
Updated by Sergey Enns over 12 years ago
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.
Updated by Tim Pray over 4 years ago
Toshi MARUYAMA wrote:
Do not post to closed issue.
I think there is a feature request for this.