Patch #7444

Patch for improved issue edit permissions

Added by Brian Lindahl over 8 years ago. Updated almost 7 years ago.

Status:ClosedStart date:2011-01-25
Priority:NormalDue date:
Assignee:Brian Lindahl% Done:

100%

Category:Issues permissions
Target version:-

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)

issue-permissions-1.0.4.patch Magnifier (12.2 KB) Brian Lindahl, 2011-01-25 19:43

issue-permissions-1.1.0.patch Magnifier (14.7 KB) Brian Lindahl, 2011-01-26 22:13

issue-permissions-1.1.0.patch Magnifier - bugfix1 (14.7 KB) Brian Lindahl, 2011-02-04 19:43

issue-permissions-1.1.0.patch Magnifier - bugfix2 (14.5 KB) Brian Lindahl, 2011-02-09 18:38


Related issues

Related to Redmine - Feature #1248: New Permission: Edit own issues Closed 2008-05-16
Related to Redmine - Patch #3461: Manage permission on issue assigment Closed 2009-06-08
Related to Redmine - Feature #7557: Deny editing of descriptions of closed issues Closed 2011-02-05
Related to Redmine - Feature #5195: edit_own_issues and delete_own_issues permissions New 2010-03-26
Related to Redmine - Feature #8082: Issue controls New 2011-04-06
Related to Redmine - Feature #8134: Restrict edit issue possibilities per role Closed 2011-04-12
Related to Redmine - Feature #8050: Mightful workflow field enhancement: visible, read only ... Closed 2011-04-03

History

#1 Updated by Brian Lindahl over 8 years ago

Please add relations to #1248 and #1445.

#2 Updated by Brian Lindahl over 8 years ago

Improvements made:
  • 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

#3 Updated by Brian Lindahl over 8 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!

#4 Updated by Brian Lindahl over 8 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'.

#5 Updated by hendro utomo over 8 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?

#6 Updated by Brian Lindahl over 8 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

#7 Updated by Brian Lindahl over 8 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.

#8 Updated by Terence Mill over 8 years ago

+1 to move to trunk

#9 Updated by hendro utomo over 8 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

#10 Updated by Maxim Antufyev over 8 years ago

Should this patch fit redmine 1.1.1 ? Or I have to downgrade to 1.1.0 ?

#11 Updated by Brian Lindahl over 8 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

#12 Updated by hendro utomo over 8 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

#13 Updated by Brian Lindahl over 8 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.

#14 Updated by hendro utomo over 8 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 :)

#15 Updated by hendro utomo over 8 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

#16 Updated by Brian Heasley over 8 years ago

Great patch, is this for sure going into 1.2? It really is need.

Any word on 1.1.1 compatibility?

#17 Updated by Brian Lindahl over 8 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.

#18 Updated by Carlo Landmeter over 8 years ago

Would love to see this included.

#19 Updated by Brian Heasley over 8 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.

#20 Updated by Brian Lindahl over 8 years ago

Brian,

The 'Edit Issue Planning' permission would solve your problem.

#21 Updated by Brian Heasley over 8 years ago

Brian: Thanks, I see that now, sorry I missed it. I do hope this makes it into the Redmine trunk.

#22 Updated by Terence Mill over 8 years ago

+1

#23 Updated by Terence Mill over 8 years ago

Why is percent done only 80%? Are there still tests for this new features?

#24 Updated by Brian Lindahl over 8 years ago

Yes, 80% done because there are no tests written for this patch.

#25 Updated by Pierre MARC over 8 years ago

This functionality is important for our organization. When do you think this would be available in an offical release ?

#26 Updated by Terence Mill over 8 years ago

covered by spec #8050

#27 Updated by Digital Dude over 8 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?

#28 Updated by Глюк Красношахтинский over 8 years ago

will this patch be included into future versions?

#29 Updated by Terence Mill over 8 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.

#30 Updated by Guy Barnhart-Magen almost 8 years ago

is there a chance to get an update for version 1.3.0?

#31 Updated by Brian Lindahl almost 7 years ago

  • Status changed from New to Resolved
  • % Done changed from 50 to 100

Resolved, more or less, in #8050.

#32 Updated by Etienne Massip almost 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF