Patch #7444
closedPatch for improved issue edit permissions
Added by Brian Lindahl over 13 years ago. Updated over 11 years ago.
100%
Description
This patch creates two new issue editing permissions:
Edit Own Issues¶
With this permission, as an author, you can edit the issue until the issue has been assigned. With this permission, as an assignee, you can edit the issue until the issue is de-assigned or assigned to someone else. This role is useful to assign to the reporter role and a restricted developer role (i.e. non software lead).
Edit Issue Planning¶
With this permission, you may edit issue planning attributes (assignee, start date, due date, estimated time, done%, and target version). This permission is useful to assign to the reporter role, and useful to assign to a restricted developer role (i.e. non software lead).
Additional modifications:¶
- subject and description can only be edited by the author before assigned unless the user has the global 'edit issues' permission (this is to prevent the subject and description changing, once the workflow is in motion)
Future improvement:¶
- add additional permission for 'progress' to allow a restricted developer role to mark progress (done% and estimated hours)
Files
issue-permissions-1.0.4.patch (12.2 KB) issue-permissions-1.0.4.patch | Brian Lindahl, 2011-01-25 19:43 | ||
issue-permissions-1.1.0.patch (14.7 KB) issue-permissions-1.1.0.patch | Brian Lindahl, 2011-01-26 22:13 | ||
issue-permissions-1.1.0.patch (14.7 KB) issue-permissions-1.1.0.patch | bugfix1 | Brian Lindahl, 2011-02-04 19:43 | |
issue-permissions-1.1.0.patch (14.5 KB) issue-permissions-1.1.0.patch | bugfix2 | Brian Lindahl, 2011-02-09 18:38 |
Related issues
Updated by Brian Lindahl over 13 years ago
Updated by Brian Lindahl over 13 years ago
- File issue-permissions-1.1.0.patch issue-permissions-1.1.0.patch added
- % Done changed from 50 to 80
- migrated to Redmine 1.1.0
- added 'edit progress' permission
- changed 'edit own issue' permission to separate 'edit authored issue' and 'edit assigned issue' permissions
- improved restrictions on subject/description editing (edit authored issue)
- improved restrictions on properties editing (the author can now edit properties once the issue is closed - for re-opening purposes)
- updated 'safe_attributes' to correlate to new permissions
Updated by Brian Lindahl over 13 years ago
- Assignee set to Jean-Philippe Lang
I've assigned this to you, since I couldn't find a better way to notify you of this patch for improvements to the edit issue permissions. If you wish to include it, this patch seems like a good candidate for 1.2.0, given the other work being done in this area. There might be some minor integration/overlap with #2732. Let me know if you need help sorting this integration/overlap out.
Also check out #7443. While not related to the other fixes going on in this area, it solves a MAJOR unsolved problem with Redmine for a large number of your community (#1675 and #685).
Thanks!
Updated by Brian Lindahl over 13 years ago
Fixed a minor bug in 'lib/redmine/default_data/loader.rb' where the Reporter role was assigned the 'edit_own_issues' permission (which was changed in the 1.1.0 patch). The role was supposed to be assigned the 'edit_authored_issues'.
Updated by hendro utomo over 13 years ago
hi brian,.very helpfull patch,. but i can't apply it against my redmine instance, it get "patch: ** Only garbage was found in the patch input.". i've try it using redmine 1.1 stable. is there something i'm missing out?
Updated by Brian Lindahl over 13 years ago
Are you using GNU patch? It works fine for me on a fresh copy of redmine 1.1 stable and the patch file directly downloaded from here. Maybe you copied and pasted the patch file rather than downloading it?
C:\redmine-1.1.0-issue-permissions>dir Volume in drive C has no label. Volume Serial Number is B0F5-5D37 Directory of C:\redmine-1.1.0-issue-permissions 02/09/2011 10:14 AM <DIR> . 02/09/2011 10:14 AM <DIR> .. 01/09/2011 05:05 PM 322 .gitignore 01/09/2011 05:05 PM 317 .hgignore 02/09/2011 10:15 AM <DIR> app 02/09/2011 10:14 AM <DIR> config 02/09/2011 10:14 AM <DIR> db 02/09/2011 10:14 AM <DIR> doc 02/09/2011 10:14 AM <DIR> extra 02/09/2011 10:14 AM <DIR> files 02/09/2011 10:12 AM 15,061 issue-permissions-1.1.0.patch 02/09/2011 10:14 AM <DIR> lib 02/09/2011 10:14 AM <DIR> log 02/09/2011 10:14 AM <DIR> public 01/09/2011 05:05 PM 307 Rakefile 01/09/2011 05:05 PM 208 README.rdoc 02/09/2011 10:14 AM <DIR> script 02/09/2011 10:14 AM <DIR> test 02/09/2011 10:14 AM <DIR> tmp 02/09/2011 10:14 AM <DIR> vendor 5 File(s) 16,215 bytes 15 Dir(s) 205,845,831,680 bytes free C:\redmine-1.1.0-issue-permissions>patch -p1 < issue-permissions-1.1.0.patch patching file app/controllers/issues_controller.rb patching file app/models/issue.rb Hunk #2 succeeded at 246 with fuzz 1. patching file app/models/mail_handler.rb patching file app/views/issues/_attributes.rhtml patching file app/views/issues/_edit.rhtml patching file app/views/issues/_form_update.rhtml patching file config/locales/en.yml patching file lib/redmine/default_data/loader.rb patching file lib/redmine.rb
Updated by Brian Lindahl over 13 years ago
I should probably explain why I did this:
changed 'edit own issue' permission to separate 'edit authored issue' and 'edit assigned issue' permissions
The use case here, is that you may want to assign an issue back to the author for feedback. However, you still want to prevent the author from changing the issue's properties. That said the issue-permissions-1.1.0-bugfix1 didn't enforce this. I've fixed this problem in issue-permissions-1.1.0-bugfix2.
Updated by hendro utomo over 13 years ago
Are you using GNU patch? It works fine for me on a fresh copy of redmine 1.1 stable and the patch file directly downloaded from here. Maybe you copied and pasted the patch file rather than downloading it?
i'm sory brian, it looks like i've downloaded the wrong file :P, i'm sory, the patch works great, but i had to use
patch -p1 < your.patch
thank you very much, this is very useful patch
Updated by Maxim Antufyev over 13 years ago
Should this patch fit redmine 1.1.1 ? Or I have to downgrade to 1.1.0 ?
Updated by Brian Lindahl over 13 years ago
I'm only maintaining this patch across stable major versions. It should work, but I have not tested it with 1.1.1.
Also related to #5195
Updated by hendro utomo over 13 years ago
hello again brian,...i got a litle more problem regarding your patch, not how to patch it :P, but rather it's functionality. Let say user A, user B and User C. User A create an issue and assign it to User B, and before user B got the chance to update this issue, user A add notes first. My problem is, whenever this action happen, assignee always change to User C, which is the default assigne for this project, and User C had to assign it back to User B in order the workflow to proceed. So, is there some thing wrong?
for information,
1. i also use Auto Assigned Issue by Ludovic Gasc. If an user forget to assign the issue, this plugin will auto-assign to the project manager.
2. User C as Project Manager
3. User A as Consultant
4. User B as Developer
Updated by Brian Lindahl over 13 years ago
Which is the problem?
1) when user A adds notes, the assignee changes to user C?
or
2) user C is required to assign the issue back to user B (user B can't do it himself - no permission)?
If the problem is 1), then problem is in the 'auto assigned issue' plugin.
If the problem is 2), then user B (who only has the 'edit assigned issues' permission) is prohibited from updating the issue, since it's NOT assigned to user B, but assigned to user C. This is expected behavior. By giving user B the 'edit all issues' permission, then user B can edit the issue, even if it's assigned to user C. Note that a user has to have the 'edit issue planning' permission in order to edit the 'assigned to' field.
Updated by hendro utomo over 13 years ago
Brian Lindahl wrote:
Which is the problem?
1) when user A adds notes, the assignee changes to user C?
If the problem is 1), then problem is in the 'auto assigned issue' plugin.
yup, point no 1 is my problem, just to make sure, im going check on this plugin again. thx brian, i'll post about this as soon as i get my answer :)
Updated by hendro utomo over 13 years ago
hi brian,
could you look into this script for me?i'm not really a programmer
module AutoAssignedUser class Hooks < Redmine::Hook::ViewListener def controller_issues_new_before_save(context) autoset_user(context) end def controller_issues_edit_before_save(context) autoset_user(context) end def autoset_user(context) @settings ||= Setting.plugin_redmine_auto_assigned_user if context[:params][:issue] if context[:params][:issue][:assigned_to_id].blank? unless context[:issue].project.members.find(:all, :conditions => ["user_id = ? AND role_id IN (?)", User.current.id, @settings['client_roles'].collect(&:to_i)], :include => [:user, :roles]).first.blank? # If the user is the client, fill the "assigned to" field users_list = context[:issue].project.users_by_role manager_role = Role.find(@settings['project_manager_role'].to_i) context[:issue].assigned_to_id = users_list[manager_role].first.id unless users_list[manager_role].blank? end end end end end end
Updated by Brian Heasley over 13 years ago
Great patch, is this for sure going into 1.2? It really is need.
Any word on 1.1.1 compatibility?
Updated by Brian Lindahl over 13 years ago
Not sure. It would probably work just fine for 1.1.1, though. As far as I know, this patch is not going into v1.2.
Updated by Brian Heasley over 13 years ago
Our problem is Reporters assigning issues to developers as mentioned in RM #3461. Would this patch cover that? I can't tell if Edit Own Issue would give the reporter the ability to also assign it.
Updated by Brian Lindahl over 13 years ago
Brian,
The 'Edit Issue Planning' permission would solve your problem.
Updated by Brian Heasley over 13 years ago
Brian: Thanks, I see that now, sorry I missed it. I do hope this makes it into the Redmine trunk.
Updated by Terence Mill over 13 years ago
Why is percent done only 80%? Are there still tests for this new features?
Updated by Brian Lindahl over 13 years ago
Yes, 80% done because there are no tests written for this patch.
Updated by Pierre MARC over 13 years ago
This functionality is important for our organization. When do you think this would be available in an offical release ?
Updated by Digital Dude over 13 years ago
- Assignee changed from Jean-Philippe Lang to Brian Lindahl
- % Done changed from 80 to 50
Redmine should enable setting permissions for issue priority & target version individually.
When patching up for this?
Updated by Глюк Красношахтинский about 13 years ago
will this patch be included into future versions?
Updated by Terence Mill about 13 years ago
The problem with that patch is that it is very special to certain type of project type.
It would be better to make it configurable which fields in trackers can be
- visible (not visible)
- read only (writable))
- mandatory (optional writable)
dependent on role and status.
See #8050 for a brife description. #8050 will also cover this feature.
Updated by Guy Barnhart-Magen over 12 years ago
is there a chance to get an update for version 1.3.0?
Updated by Brian Lindahl almost 12 years ago
- Status changed from New to Resolved
- % Done changed from 50 to 100
Resolved, more or less, in #8050.
Updated by Etienne Massip over 11 years ago
- Status changed from Resolved to Closed