Feature #5011
Limit Visible Issue Fields Based on Permissions
| Status: | Closed | Start date: | 2010-03-08 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Issues permissions | |||
| Target version: | - | |||
| Resolution: | Duplicate |
Description
Allow the ADMIN to configure which fields appear when creating/viewing/editing an issue, based on the permissions of the logged in user.
A coy should only copy the fields that the user copying the issue can see in the display.
For instance, allow the developers to enter comments in fields on an issue but do not have these fields appear for the client.
Adding a feature like this would negate the need for Redmine to instruct folks entering issues to not use the Assigned-To field, as that field should not be visible to all folks reporting issues or requesting features.
Related issues
History
#1
Updated by Walther Lalk about 10 years ago
Doing the much hated +1 here.
I would love to see this feature in a future version of Redmine. We are currently incorporating Redmine into our project workflow and the only thing that is missing is the ability to set which fields a user can access when creating a new issue.
In our case we don't want our clients to be able to set the 'assign to', due dates, % done, etc.
#2
Updated by Eric Davis almost 10 years ago
- Category changed from Administration to Issues permissions
- Priority changed from High to Normal
#3
Updated by pasquale [:dedalus] over 9 years ago
+1
We have various related\dupes tickets on this: it's seems that more users want to manage "native\custom field by role"!
#4
Updated by anonymous incognito over 9 years ago
What, the issue has been there for a whole year yet nobody has bothered to fix it? Not cool, people, there's lots of serious organisations using this software, can't just ignore everyone, you know?
#5
Updated by Terence Mill over 9 years ago
dupes some parts of #8050
#6
Updated by @ go2null over 7 years ago
Should be considered a duplicate of Feature #12005.
#7
Updated by @ go2null over 7 years ago
- Status changed from New to Resolved
Should be considered a duplicate of Feature #12005.
#8
Updated by Daniel Felix over 7 years ago
Closed as duplicate of #12005. Thanks!
#9
Updated by Daniel Felix over 7 years ago
- Status changed from Resolved to Closed
- Resolution set to Duplicate