Feature #1248

Permissions - Edit own issues

Added by Ronie Henrich about 4 years ago. Updated 3 months ago.

Status:New Start date:2008-05-16
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:Permissions and roles
Target version:Candidate for next major release
Resolution:

Description

  • Today (as in version 0.7.1):
    • We may only grant/revoke a role the permission to edit any issues ("Edit issues" permission).
  • Suggestion / Request:
    • It would be nice to be able to grant/revoke a role the permission to "Edit own issues".

0001-Added-edit_own_issues-and-edit_own_new_issues-permis.patch (5.9 kB) Magnifier Leo Hourvitz, 2010-10-08 05:41


Related issues

related to Patch #7444: Patch for improved issue edit permissions New 2011-01-25
duplicated by Feature #8805: Please consider to make a new permission for "edit _own_ ... Closed 2011-07-13

History

#1 Updated by Jean-Philippe Lang over 3 years ago

  • Target version deleted (0.8)

#2 Updated by Daniel Jones about 3 years ago

+1

#3 Updated by Royce Williams about 2 years ago

+1. Empowering users to modify their own request can reduce the load on the people processing requests.

#4 Updated by Алексей Лошкарёв almost 2 years ago

+1 This may reduce count of misspelled or invalid bug. Because user may do mistake on filling bug.

#5 Updated by Leo Hourvitz over 1 year ago

I have a patch for this against recent trunk, attached. We are having this problem in a big way at an installation of mostly native Japanese speakers; with Asian languages, you're always hitting return to do Kanji conversion of your input and one extra carriage return means a half-baked issue in the tracker!

New Permissions

I addressed this by creating two new permissions that can be assigned to roles:
  • edit_own_issues allows users with that permission to edit issues they created (i.e., whose author field is equal to the current user). This addresses the problem, but is potentially a big workflow change, so not all sites might want it.
  • edit_own_new_issues is a more limited permission that allows a user to edit their own issues if there are no journals yet, or if all existing journals were created by the author. I think this is really the pinpoint solution to the problem; as far as I know, all edits will create a journal, so this lets you edit your issue until the moment someone else pays attention to it.
    • Because it seems like such a contained right, in the patch I added it to the default permissions for the Reporter role.

Implementation

To implement the above, I created a new editable? predicate on the issue model parallel to the visible? predicate that was already there (this also seems like a pretty good pattern to follow in general). Then, I changed the code that was doing
User.current.allowed_to?(:edit_issues, @project)
to just call
issue.editable?
instead.

I updated the English and Japanese locales as well.

The patch file was formatted with git format-patch; is that the preferred patch format? Specifically, the patch was generated against svn+ssh://rubyforge.org/var/svn/redmine/trunk@4175 e93f8b46-1217.

I'm fairly new to Redmine and Ruby, so it would definitely be good to get other eyes on this patch. I'll be able to get in some more testing next week. My configuration is:

bash-3.2$ RAILS_ENV=production ruby script/about
About your application's environment
Ruby version              1.8.7 (universal-darwin10.0)
RubyGems version          1.3.5
Rack version              1.0
Rails version             2.3.5
Active Record version     2.3.5
Active Resource version   2.3.5
Action Mailer version     2.3.5
Active Support version    2.3.5
Application root          /Users/leo/OpenSrcSources/redmine
Environment               production
Database adapter          mysql
Database schema version   20100819172912

#6 Updated by Leo Hourvitz over 1 year ago

I also applied this patch on our production redmine at work (Redmine 1.0.1 release on CentOS 5.2).

#7 Updated by Nathan Eggen over 1 year ago

+1 - this should go in the trunk.

#8 Updated by Bernhard Furtmueller over 1 year ago

+1

#9 Updated by Brian Lindahl over 1 year ago

Created patch issue to follow the progression of my patch to add this feature and other issue edit permission improvements. Please add relation to #7444.

#10 Updated by Leo Hourvitz over 1 year ago

Is there any approved way to urge this get moved to trunk? I need to apply this on every Redmine instance we use, I think any installation with real scale of users is unmanageable without something like this.

Brian: I don't seem to have permissions to add the relation.

#11 Updated by Brian Lindahl over 1 year ago

Leo: Issue relations in Redmine are controlled by a different permission: 'Manage issue relations'. I can see a situation where project managers/software leads would not want issue reporters to have the ability to set up relations. Perhaps another permission should be added: 'Manage own issue relations'?

#12 Updated by Brian Lindahl over 1 year ago

Leo: Hah! Just realized that you were saying that you don't have the permissions to relate this issue to my patch issue #7444.

#13 Updated by Etienne Massip 11 months ago

  • Target version set to Candidate for next major release

#14 Updated by Gokay Gok 5 months ago

+1

#15 Updated by Aleksej Lebedev 4 months ago

+1

#16 Updated by Yannick Recht 3 months ago

+1 also.

It should be interesting to add this parameter.

Also available in: Atom PDF