Feature #12089
open
Hide Issue History
0%
Description
hello,
We are using redmine to manage our change management processes.
The functional user open end close the issue, other status are dealt by IT team. My problem is that i don’t want to give the functional user the ability to view the history or details of the issue ( what IT team are doing).
My questions are ?
- Can i hide issue details based on user role or permission ?
- Can i disable clickable links to on the issues list view based on role ?
If not, what can i do ?
Thanks
Related issues
Updated by
Updated by Igor Deyashkin over 11 years ago
I have a similar problem and private comments not resolve it.
Status change and reassignment are visible for functional users, but i want to hide it.
Functional user must have ability to see changes of task, only when it assigned to him in this change.
Thanks.
Updated by Adam Kubica about 10 years ago
+1, private comments doesn't resolve problem.
Updated by Go MAEDA almost 10 years ago
- Related to Feature #15409: Is it possible to view History section in pages? added
Updated by Go MAEDA almost 10 years ago
- Related to deleted (Feature #15409: Is it possible to view History section in pages?)
Updated by 
Updated by Toshi MARUYAMA 
Updated by 
Updated by
Updated by Go MAEDA almost 8 years ago
- Has duplicate Feature #24806: Possibility to hide Issue History from a role added
Updated by Go MAEDA almost 8 years ago
- Related to Feature #9432: Default value for the private issue flag added
Updated by Wim DePreter almost 8 years ago
possible workaround: create subtasks with tracker that is only visible for IT-team (see #285), that way IT-team-history is not visible for other users
Updated by Arnaud Pissot almost 8 years ago
Wim DePreter wrote:
possible workaround: create subtasks with tracker that is only visible for IT-team (see #285), that way IT-team-history is not visible for other users
Thanks for the information !
It works, I will see with our project manager if this workaround can solve this problem for now.
Problems seen with this workaround:
- it's a bit tricky as the status of the parent do not change when the children is updated (only % is updated)
- I got one tracker not visible (the IT one) for 9 trackers visibles by customers (I don't want to duplicate every tracker and get 18 trackers, it will be automatically refused by my hierarchy)
Updated by Wim DePreter almost 8 years ago
Arnaud Pissot wrote:
Problems seen with this workaround:
- it's a bit tricky as the status of the parent do not change when the children is updated (only % is updated)
- I got one tracker not visible (the IT one) for 9 trackers visibles by customers (I don't want to duplicate every tracker and get 18 trackers, it will be automatically refused by my hierarchy)
It was just a suggestion. We faced the same problem in version 3.0 (#285 wasn't resolved), and created a separate IT-project, used "blocked by" relation instead of subtasks, but that is more complex (extra relation has to be added). We didn't duplicate trackers, because visibility was controlled on project-base.
For status-synchronisation, we have a batch-job (than runs every X minutes) that synchronises states via rest-API.
Updated by Arnaud Pissot almost 8 years ago
Wim DePreter wrote:
Arnaud Pissot wrote:
Problems seen with this workaround:
- it's a bit tricky as the status of the parent do not change when the children is updated (only % is updated)
- I got one tracker not visible (the IT one) for 9 trackers visibles by customers (I don't want to duplicate every tracker and get 18 trackers, it will be automatically refused by my hierarchy)It was just a suggestion. We faced the same problem in version 3.0 (#285 wasn't resolved), and created a separate IT-project, used "blocked by" relation instead of subtasks, but that is more complex (extra relation has to be added). We didn't duplicate trackers, because visibility was controlled on project-base.
For status-synchronisation, we have a batch-job (than runs every X minutes) that synchronises states via rest-API.
Yeah I'm really thankful for your solution,
we already have the "Custom workflows" plugin which can allow me to replicate the status of the issue to its parent but I prefer to not use plugins and tricks everywhere to get our Redmine working smooth as possible and avoid bugs :)
Updated by