#3163 closed enhancement (fixed)
Implement Description field modification permission outside TICKET_ADMIN level
Reported by: | anonymous | Owned by: | Christian Boos |
---|---|---|---|
Priority: | high | Milestone: | 0.11 |
Component: | ticket system | Version: | 0.9.5 |
Severity: | major | Keywords: | PermissionPolicy |
Cc: | nulleke76@…, frans.godschalk@…, trac-ja@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I've found a very limiting restriction not being able to give Description field modification permission to users without TICKET_ADMIN privileges.
I see two solutions:
- moving Description field modification permission to TICKET_MODIFY level
- creating a new permission level between TICKET_MODIFY e TICKET_ADMIN (TICKET_SUPERVISOR, for example) with Description field modification permission
Attachments (1)
Change History (18)
comment:1 by , 19 years ago
Owner: | changed from | to
---|
follow-up: 3 comment:2 by , 18 years ago
Milestone: | → 0.11 |
---|
Maybe this should become configurable, e.g.
[ticket] editable_description = false
(= current behavior, could be the default)
comment:3 by , 18 years ago
Replying to cboos:
Maybe this should become configurable, e.g.
[ticket] editable_description = false(= current behavior, could be the default)
I think a new permission would be more appropriate. TICKET_ADMIN
would of course already have the new permission, but this permission could also be given to other users independent of the rest of the TICKET_
permissions.
follow-up: 5 comment:4 by , 18 years ago
I think a configuration option is not a great solution because this is really a permissions issue.
Adding to an existing permission (TICKET_CHGPROP
or TICKET_MODIFY
) would be a good solution. Adding another TICKET_
permission would work as well, but there are quite a few TICKET_*
permissions already, and adding too many will start to get tedious if you have to assign permissions for editing every field.
comment:5 by , 18 years ago
Keywords: | PermissionPolicy added |
---|
Replying to sid:
Adding another
TICKET_
permission would work as well, but there are quite a fewTICKET_*
permissions already, and adding too many will start to get tedious if you have to assign permissions for editing every field.
Ideally, this would be an EDIT permission on the ticket description field. I wonder if we could add the field granularity to the fine-grained permissions…
It would certainly be more convenient to implement as a new TICKET_EDIT permission, though.
comment:6 by , 18 years ago
Cc: | added |
---|
follow-up: 8 comment:7 by , 18 years ago
Another idea is to only allow editing of the description field for TICKET_CHGPROP for people that initiated the ticket (until it is accepted by the person that is assigned to it.) after that the assigned person will be able to edit the ticket description.
comment:8 by , 18 years ago
Replying to nulleke76@gmail.com:
This could probably be done by a PermissionPolicy plugin, after the TICKET_EDIT permission has been added.
comment:9 by , 18 years ago
Summary: | Implement Description field modification permission outside TICKET_ADMIN level → Implement Description field modification permission outside11 TICKET_ADMIN level |
---|
comment:10 by , 17 years ago
Severity: | normal → major |
---|---|
Summary: | Implement Description field modification permission outside11 TICKET_ADMIN level → Implement Description field modification permission outside TICKET_ADMIN level |
comment:11 by , 17 years ago
#5251 is marked as duplicate of this ticket. It requests finer grained control over ticket permissions. Specifically, it asks for a separate permission for changing the ticket resolution.
comment:12 by , 17 years ago
Priority: | normal → high |
---|
by , 17 years ago
Attachment: | Trac-0.11dev_r6814_ticketdescription.patch added |
---|
Patch againsts source:trunk@6814
comment:14 by , 17 years ago
Milestone: | 0.11.1 → 0.11 |
---|
Thanks for the patch (and please once again: could you tell us who's behind the trac-ja@ address, so that we can fix the THANKS file?)
comment:15 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I would suggest the first case, provided we also give access to the Description change history (see #2945)