Feature #8050
closedMightful workflow field enhancement: visible, read only and mandatory
Added by Terence Mill over 13 years ago. Updated over 5 years ago.
0%
Description
The problem with a bigger workflow is that some of the fields should be only visible at a later status (e.g. status=Test, which needs additional fields like "tester"), or the field should be set by a certain role only (field is readonly for other roles, e.g. progress is only used in development stage by developers) or a status can only be changed if a certain field is set (field is mandatory for status change and and role, e.g time estimatation must be set before status can change to planning)
I would propose a easy but mightful enhancement which will solve them all:
There should be a matrix to set rights, visibility and duty dependent on role and status
in every cell in the matrix there is a row for every field of tracker and every row has field name followed by 3 checkboxes:
- visible (not visible)
- read only (writable))
- mandatory (optional writable)
Rules:
- if field is visible (visible=false then 2 and 3 are greyed)
- if field id read only (1 is true, read only=true then 3 is greyed)
- if field is mandatory ( 1 is true, 2 is false)
Since some users won't need this kind of advanced workflow there could be a default for this 3 properties for all fields.
Today the default is visible=true, read only=false and mandatory=false (Except Subject ;) )
Files
Screenshot0.jpg (23.1 KB) Screenshot0.jpg | Terence Mill, 2011-05-18 15:56 | ||
Screenshot1.jpg (65.3 KB) Screenshot1.jpg | Terence Mill, 2011-05-18 15:56 | ||
Screenshot2.jpg (344 KB) Screenshot2.jpg | Terence Mill, 2011-05-18 15:56 | ||
workflow_permissions.png (13.7 KB) workflow_permissions.png | Jean-Philippe Lang, 2012-07-15 18:26 | ||
NoRedStarForMandatoryField.png (49.2 KB) NoRedStarForMandatoryField.png | Gurvan Le Dromaguet, 2012-09-03 16:05 | ||
workflow_hidden_field.diff (4.79 KB) workflow_hidden_field.diff | Gurvan Le Dromaguet, 2012-09-28 12:29 | ||
workflow_hidden_field_v0.03.diff (8.73 KB) workflow_hidden_field_v0.03.diff | Added possiblity to hide non-custom_fields | Gurvan Le Dromaguet, 2012-10-02 11:27 |
Related issues
Updated by pasquale [:dedalus] over 13 years ago
+1
fundamental feature for redmine: in real world more fields are only for developers, others for reporter...
Updated by pasquale [:dedalus] over 13 years ago
Terence Mill wrote:
I propose to remove them in favour or this ticket.
Hope thas helps to clear some things anf go forward a solution.
I agree too: who can make this decision here? Etienne?
Updated by pasquale [:dedalus] over 13 years ago
dedalus - wrote:
I agree too: who can make this decision here? Etienne?
errata:
except for issue #703 that isn't related to generici "set fields visibility\locking per user role"
Updated by Terence Mill over 13 years ago
#703 is also covered, required fields can be set for all status for a role, if it should not be limited for one status only.
I will try to create a tiggr wireframe prototype of the matrix gui for better imagination.
dedalu- wrote:
dedalus - wrote:
I agree too: who can make this decision here? Etienne?
errata:ix
except for issue #703 that isn't related to generici "set fields visibility\locking per user role"
Updated by Terence Mill over 13 years ago
I make a first gui wire freame how it could look like.
In the upper table you see the standard redmine worfflow transistion matrix. Just below the advanced issue field configuration table can be dropped down, where field property (visible, read only, mandatory) can be set dependent on role and status. For this case you wanna set field property for all status the same value, weh could insert an button to help with this, copy from the first cell in first column
Notice that there is also a special role "author", this way rights and visbility of fields can be configured for the issue author whatever role he has. This way functionality from #7444 is covered by configuration.
Also notice that the table contains all fields (means standard redmine fields - subject and description too - and of course all user defined fields of the choosen tracker).
The logic for the visible chechbox (field is visible) and radio button "read only" (not writable) and mandatory (must be set by role in given status) is as explained in issue description - see above.
See the wire frame demo
Updated by pasquale [:dedalus] over 13 years ago
Updated by Terence Mill over 13 years ago
I did an update on the demo and fixed a bug, now there a 3 radio buttons.
All options for the field get active for the user if he has selected role and the status has the value of the column you do set the following field options.
- visible - this has to be checked in any case one of the following radio options can work. If its not checked the user can't see the field at the issue form.
- read only - if this is checked user in selected role can only see the field (of course visible has to be checked also) but can't change value.
- read,write - if this is checked user can see and edit the field
- mandatory - the user has to set a value, if its not already set. If its set he can't just leave it or change it, i he wants.
Furthermore i added a drop down for every field, where one can set/change the order of the fields. At the moment there are some field in a on column layout at the top of the form and other are spread in a two column layout at the bottom. Not sure how to handle these assigment, but at least order in the two column layout could be configurable with this new control. Number in the drop-down equates the position top-down in the layout.
Any sugesstions and contrbutions to change or add this demo as visual specification are welcome.
Updated by Terence Mill about 13 years ago
Furthermore i added a drop down for every field, where one can set/change the order of the fields. At the moment there are some field in a on column layout at the top of the form and other are spread in a two column layout at the bottom. Not sure how to handle these assigment, but at least order in the two column layout could be configurable with this new control. Number in the drop-down equates the position top-down in the layout.
According to the configuration for column layout, there is piece of code which could be used and refactored to configure in which column the field shall be showed. See Single column custom fields
Updated by Terence Mill about 13 years ago
- File Screenshot0.jpg Screenshot0.jpg added
- File Screenshot1.jpg Screenshot1.jpg added
- File Screenshot2.jpg Screenshot2.jpg added
Screeners of the demo
Updated by Terence Mill about 13 years ago
Terence Mill wrote:
Furthermore i added a drop down for every field, where one can set/change the order of the fields. At the moment there are some field in a on column layout at the top of the form and other are spread in a two column layout at the bottom. Not sure how to handle these assigment, but at least order in the two column layout could be configurable with this new control. Number in the drop-down equates the position top-down in the layout.
According to the configuration for column layout, there is piece of code which could be used and refactored to configure in which column the field shall be showed. See Single column custom fields
I thought aboot a mightyful approach to make the issue form layout completly configurable and i found it!
Being able to set issue form layout, would need a to configure table cell for every field.
E.g
field | column | row |
title | 1 | 1 |
subject | 1 | 2 |
description | 1 | 3 |
Status | 1 | 4 |
Priority | 1 | 5 |
Assignee | 1 | 6 |
Category | 1 | 7 |
Affected version | 1 | 8 |
Start date | 2 | 4 |
Due date | 2 | 5 |
Estimated time Hours | 2 | 6 |
%Done | 2 | 7 |
Resolution | 2 | 8 |
Files | 1 | 9 |
The algo to make a table layout of this is pretty simple. It has to search for all list entries with same row number and make a table with number of columns used in this rows. In the redmines standard issue form case (see table above) first 3 rows have one column layout, row 4-8 have 2 column layout and row 9 has one column again).
I will advance the wireframe demo with this new settings these days.
Updated by Maarten Klerk about 13 years ago
I am switching from Trac to Redmine. I would very much appreciate it if the issue described here will be included in a next version.
I see it as a major drawback that I cannot prevent users to assign tasks to other users (even in the same project). Basic implementation could be to add a seperate right 'edit assignee'.
Updated by Benjamin Bohn about 13 years ago
- Assignee set to Terence Mill
When will this feature be released? Or is a plugin available?
Updated by Seth Sandler about 13 years ago
Is this available somewhere? Is it just a mockup or is this actually working code?
Updated by Terence Mill about 13 years ago
Its a mockup for better requirements definition.
Seth Sandler wrote:
Is this available somewhere? Is it just a mockup or is this actually working code?
Updated by Seth Sandler about 13 years ago
This may be useful. It has some of the features and seems like it could be extended a bit to provide all of them. http://9thport.net/2011/03/20/redmine-hide-assigned-to-field-with-role-permissions-plugin/comment-page-1/#comment-11358
Updated by Mathieu Rochette almost 13 years ago
+1
we'd like to prevent non-member to set assigned to and priority
Updated by Sławomir Kaimakami almost 13 years ago
+1 +1 +1
We need this so much...
For me and my company this is the most important functionality that is missing in Redmine.
Updated by Kasper Pagels almost 13 years ago
+1
Any news to when this will be available? This is the one and only reason why we struggle migrating fully to redmine. That is a shame since redmine is a powerful tool.
Updated by Kasper Pagels almost 13 years ago
I can see here that I am able to edit only the status, assignee and percent done. How did you limit that?
Updated by ja dwa over 12 years ago
Hi,
I wonder about issue's fields permission solution. Is it hard to add such feature to redmine? Are You planing something like that? I am not talking about solutions like this [http://9thport.net/2011/03/20/redmine-hide-assigned-to-field-with-role-permissions-plugin/]. It is simple hide field but user still has access to this field. In this case user is able to write field using REST API (if it is enable) or just use similar url [redmine/issues/[number]?auth_token=...&issue[assigned_to_id]=[id]]. I am talking about real access controll to single field. Any news in this case?
Regards
Updated by Aaron Addleman over 12 years ago
Hi Everyone,
I have modified my plugin to have a specific validation be run when changing the Assignee field and be controlled by a permission value of a role. I hope that this is a good starting point for something that I can improve upon in the future (possibly from some suggestions of people).
If you have time to share some thoughts on the plugin page, please be kind as I am a Ruby noobie.
Cheers,
Aaron
Updated by Tiemo Vorschuetz over 12 years ago
+1
This is a great feature. Any ideas when this will be available?
Updated by Anonymous over 12 years ago
+1
Would be very useful for implementing roles like 'product manager'.
Updated by Rabbit Seagraves over 12 years ago
I love this, but would it also allow an admin to edit the default fields text? for example, we tend to estimate tasks by days, rather than hours.
Updated by Holger Winkelmann about 12 years ago
Is there any progress implementing this or parts of the features described here. We are really missing a way to assign tickets either to roles or even a more flexible way
Updated by Terence Mill about 12 years ago
The function "assign issue to roles" is not part of this feature request.
This feature request is sadly not on the roadmap so far.
Updated by Terence Mill about 12 years ago
All these features are covered by feature this feature and so far are dupes.
I propose to remove them in favour or this ticket.
Hope thas helps to clear some things anf go forward a solution.
- Feature #3521: Add on/off permissions for roles to change fields in a tracker
- Feature #2500: Configure custom fields as "required for status transition"
- Feature #5067: Read only custom field
- Feature #703 : Configurable required fields
- Feature #5011: Limit Visible Issue Fields Based on Permissions
- Feature #5037: Role-based custom field visibility
- Feature #582 : Make fields mandatory/unmandatory
- Feature #1091: Disabling default ticket fields
- Feature #1360: Permission for adding an issue to a version
- Feature #1919: Separate permissions for changing assigned-to, % finished and target version
- Feature #2708: Require Category
- Feature #7694: Require permission to assign a version to an issue
- Feature #8313: Restrict Assignee List by Role
- Feature #3726: Trackers per Role
- Feature #3088: Estimated hours field able to hide role based
- Patch #7444: Patch for improved issue edit permissions
Updated by Jean-Philippe Lang about 12 years ago
- File workflow_permissions.png workflow_permissions.png added
Updated by Terence Mill about 12 years ago
Wow!. Great job. This is a major step forward using redmine for many other workflow projects beyond bug tracking only.
Looking fowrad to try ít our at demo system *m.redmine.org. At the moment there is no 2.1 version deployed.
Most of this request is now implemented for 2.1.0 (#703, #3521).
Is there a field status visible? I mean it it possible to completly hide fields for some role in some status, where other can see it?
Updated by @ go2null almost 12 years ago
Terence Mill wrote:
Is there a field status visible? I mean it it possible to completly hide fields for some role in some status, where other can see it?
Can anyone confirm that this patch does not provide the option to hide the field?
That is, there is not a "Visible" option.
Updated by Gurvan Le Dromaguet almost 12 years ago
My comments:
- The "hidden" value would really be great indeed.
- We now have two ways to set a custom field mandatory : via Admin->Custom fields or via this new feature at Workflow->Fields Permission
For now, I am trying to code a patch for the hidden attribute capability
Updated by # And almost 12 years ago
Gurvan Le Dromaguet wrote:
I had a test today installing trunk version on my workstation : great job !
My comments:
- The "hidden" value would really be great indeed.
- We now have two ways to set a custom field mandatory : via Admin->Custom fields or via this new feature at Workflow->Fields Permission
For now, I am trying to code a patch for the hidden attribute capability
This would be great. Jean-Philippe Lang, why do not realize it in 2.1.0?
pasquale [:dedalus] wrote:
+1
fundamental feature for redmine: in real world more fields are only for developers, others for reporter...
It is true. User does not need the much fields, often it is just the status and the date. Or just status. =)
Updated by Esben Haabendal almost 12 years ago
Gurvan Le Dromaguet wrote:
For now, I am trying to code a patch for the hidden attribute capability
Any news on this? I would be happy to help you test it :-)
And it would be really great if it could make it into 2.2.0. Together with #1554 it would make Redmine much more suitable for setups where you have 3 parties using the same Redmine. Internal developers, project management, and external customer/client.
Updated by Abdul Halim Mat Ali almost 12 years ago
I have upgraded to 2.1. Isn't the attributes hidden when you set it to read only?
Updated by Brian Lindahl almost 12 years ago
A very important use case is still not covered in the 2.1.0 implementation:
Reporter creates two defects, A and B
Software Lead assigns defect A to Engineer1 and defect B to Engineer2
With the current proposal (and in 2.1.0), there is still no way to allow Engineer1 to edit defect A, but prevent him from editing defect B. You can prevent status changes in 2.1.0, but you can't prevent editing in 2.1.0 (nor in this proposal).
The missing component is having three sets of field configurations, like there are for status changes:
1) all issues
2) authored issues
3) assigned issues
As such, patch #7444 is still necessary.
Updated by Gurvan Le Dromaguet almost 12 years ago
Esben Haabendal wrote:
Gurvan Le Dromaguet wrote:
For now, I am trying to code a patch for the hidden attribute capability
Any news on this? I would be happy to help you test it :-)
And it would be really great if it could make it into 2.2.0. Together with #1554 it would make Redmine much more suitable for setups where you have 3 parties using the same Redmine. Internal developers, project management, and external customer/client.
I went over a lot of wrong way to do it as I am really not expert in ruby/rails.
However I finally had something that looks like working (however not sure that the hidden works good for "native" fields)
Please find attached a patch to test on 2.1 (tested on 2.1 branch at release time)
surely not perfect coding, feedbacks/improvements are welcomed !
Updated by # And almost 12 years ago
Gurvan Le Dromaguet wrote:
Esben Haabendal wrote:
Gurvan Le Dromaguet wrote:
For now, I am trying to code a patch for the hidden attribute capability
Any news on this? I would be happy to help you test it :-)
And it would be really great if it could make it into 2.2.0. Together with #1554 it would make Redmine much more suitable for setups where you have 3 parties using the same Redmine. Internal developers, project management, and external customer/client.
I went over a lot of wrong way to do it as I am really not expert in ruby/rails.
However I finally had something that looks like working (however not sure that the hidden works good for "native" fields)
Please find attached a patch to test on 2.1 (tested on 2.1 branch at release time)
surely not perfect coding, feedbacks/improvements are welcomed !
Works fine on trunk. Gurvan Le Dromaguet, maybe create issue in order to developers apply your patch?
Updated by # And almost 12 years ago
Gurvan Le Dromaguet, it is only solution for custom fields?
Updated by Gurvan Le Dromaguet almost 12 years ago
Ok, I will submit the patch after a short testing period on my side
Attached new version, added the possibility to hide the Default fields too + found where to set a color in the workflow permissions panel for "hidden" :)
Can you apply this and confirm it works ? Thanks in advance !
Updated by # And almost 12 years ago
Gurvan Le Dromaguet, OK, I'll test it today. Additionally, I create new task about hide fields on workflow ability #12005.
Updated by Jean-Philippe Lang almost 12 years ago
- Status changed from New to Closed
I'm closing it in favour of #12005 now that the read-only/required part of this request is implemented.
Updated by Steven Wong almost 12 years ago
Nice. waiting for the next stable release.
the field with status could be set as Required, visible , disvisible or read-only. it would be much more better.
Thanks.
Jean-Philippe Lang wrote:
I'm closing it in favour of #12005 now that the read-only/required part of this request is implemented.
Updated by Heribert Steuer over 11 years ago
Hello,
first of all thanks alot for this patch, helps alot to cover our usecases!
I just applied workflow_hidden_field_v0.03.diff to Redmine 2.1.3. It seems that the field permissions are screwed up somehow. Here are the results of my first tests:
Setting field to "" displays the field as optional (okay)
Setting field to "Read-only" hides the field (not okay)
Setting field to "Hidden" displays the field optional (not okay)
Setting field to "Required" displays the field as mandatory (okay)
The patch itself applied without any problems but it might still be related to the version of redmine I´ve used. Did anyone get into this as well?
Thanks alot,
Heri
Updated by Heribert Steuer over 11 years ago
btw, the above only applies to the "New issue" form. The issues display itself seems to work as expected.
Updated by Jai prakash over 11 years ago
I applied workflow_hidden_field_v0.03.diff patch . The patch applied without any errors and it hides the fields . But while updating the issue the hidden fields are showing and i am able to update those fields.Is this a bug ? I mean if a field is hidden it should not be available for editing too right?
Updated by Gurvan Le Dromaguet over 11 years ago
jai prakash wrote:
I applied workflow_hidden_field_v0.03.diff patch . The patch applied without any errors and it hides the fields . But while updating the issue the hidden fields are showing and i am able to update those fields.Is this a bug ? I mean if a field is hidden it should not be available for editing too right?
Hello,
This ticket is closed and a separate item has been created to track the "hiding" functionality:
http://www.redmine.org/issues/12005
You will find there more recent and complete patches, please try these first.
Updated by Jai prakash over 11 years ago
jai prakash wrote:
I applied workflow_hidden_field_v0.03.diff patch . The patch applied without any errors and it hides the fields . But while updating the issue the hidden fields are showing and i am able to update those fields.Is this a bug ? I mean if a field is hidden it should not be available for editing too right?
OOPS sorry my bad . Please ignore this . I see that #12005 has it resolved .
Updated by Michael Sanders about 10 years ago
Is it possible to hide fields on the initial creation of an issue, but show them when editing an item?
I want it to be easier (read: less daunting) to create an issue in Redmine, by hiding fields that are only useful later on. I'd like to hide the fields upon creation, but show them when the issue is created and when the user is editing it.
Updated by Daniel Felix about 10 years ago
yes, it is. Just show these fields as read only for the status new in the workflow.
but beware! Required Fields should be visible. You can't hide the subject for example if this is needed.
Updated by Michael Sanders about 10 years ago
Thank you Daniel, I gave these patches a try and did as you said last week, but I may have not done it correctly. I will try again.
The fields I'd like to hide are not required, Parent Task, Estimated Time and Target Version. I'd like them to be shown after an issue is created.
Updated by Michael Sanders about 10 years ago
Daniel,
Thanks for your help. I implemented the patch, and was able to hide Parent Task, Estimated Time and Target Version on initial creation.
However, I find that these fields cannot be seen by non-Administrators after issue creation. These fields need to be viewable by non-Administrators after their issue's creation.
Additionally, I am trying to hide a custom field on initial creation, this patch does not seem to be allowing me to do that. I have the fields set as Read-Only or Required, based on their status. Should this work?
Updated by Sky Stalker over 5 years ago
https://github.com/Neticoa/redmine_workflow_hidden_fields
http://www.redmine.org/plugins/redmine_workflow_hidden_fields
this plugin can solve the problem