Feature #8050

Mightful workflow field enhancement: visible, read only and mandatory

Added by Terence Mill over 3 years ago. Updated 3 months ago.

Status:ClosedStart date:2011-04-03
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues workflow
Target version:-
Resolution:

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:

  1. if field is visible (visible=false then 2 and 3 are greyed)
  2. if field id read only (1 is true, read only=true then 3 is greyed)
  3. 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 ;) )

Screenshot0.jpg (23.1 KB) Terence Mill, 2011-05-18 15:56

Screenshot1.jpg (65.3 KB) Terence Mill, 2011-05-18 15:56

Screenshot2.jpg (344 KB) Terence Mill, 2011-05-18 15:56

workflow_permissions.png (13.7 KB) Jean-Philippe Lang, 2012-07-15 18:26

NoRedStarForMandatoryField.png (49.2 KB) Gurvan Le Dromaguet, 2012-09-03 16:05

workflow_hidden_field.diff Magnifier (4.79 KB) Gurvan Le Dromaguet, 2012-09-28 12:29

workflow_hidden_field_v0.03.diff Magnifier - Added possiblity to hide non-custom_fields (8.73 KB) Gurvan Le Dromaguet, 2012-10-02 11:27


Related issues

Related to Feature #703: Configurable required fields per tracker/status/role Closed 2008-02-21
Related to Patch #7444: Patch for improved issue edit permissions Closed 2011-01-25
Related to Feature #2539: New project setting: mandatory/optional configuration for... New 2009-01-19
Related to Feature #9700: Allow to configure the visibility of the fields of the “N... Closed
Related to Feature #9736: custom field visibility based on tracker Resolved
Related to Feature #3521: Permissions for roles to change fields per tracker/status Closed 2009-06-22
Related to Feature #2500: configure custom fields as "required for status transition" Closed 2009-01-13
Related to Feature #12005: Mightful workflow field enhancement: hide New
Related to Feature #393: Role that can't assign a ticket Closed
Related to Feature #4707: private fields New 2010-02-01
Related to Feature #8313: Restrict Assignee List by Role New 2011-05-06
Related to Feature #10162: require notes on specific fields getting set to specific ... New
Duplicated by Feature #11329: Private custom fields Closed

History

#1 Updated by pasquale [:dedalus] over 3 years ago

+1

fundamental feature for redmine: in real world more fields are only for developers, others for reporter...

#2 Updated by pasquale [:dedalus] over 3 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?

#3 Updated by pasquale [:dedalus] over 3 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"

#4 Updated by Terence Mill over 3 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"

#5 Updated by Terence Mill over 3 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

#6 Updated by pasquale [:dedalus] over 3 years ago

Terence Mill wrote:

See the wire frame demo

good mockup

#7 Updated by Terence Mill over 3 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.

#8 Updated by Terence Mill over 3 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

#9 Updated by Terence Mill over 3 years ago

Screeners of the demo

#10 Updated by Terence Mill over 3 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.

#11 Updated by Maarten Klerk over 3 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'.

#12 Updated by Benjamin Bohn over 3 years ago

  • Assignee set to Terence Mill

When will this feature be released? Or is a plugin available?

#13 Updated by Terence Mill over 3 years ago

  • Assignee deleted (Terence Mill)

#14 Updated by Brian Heasley over 3 years ago

+1

#15 Updated by Christian Köwing over 3 years ago

+1

#16 Updated by Seth Sandler over 3 years ago

Is this available somewhere? Is it just a mockup or is this actually working code?

#17 Updated by Terence Mill over 3 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?

#18 Updated by Seth Sandler over 3 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

#19 Updated by Mathieu Rochette about 3 years ago

+1

we'd like to prevent non-member to set assigned to and priority

#20 Updated by Sławomir Kaimakami about 3 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.

#21 Updated by Tony Marschall about 3 years ago

+1

#22 Updated by Pierluigi Soana about 3 years ago

+1 Very useful

#23 Updated by Darko Lombardo about 3 years ago

+1 A Must for usable Workflows

#25 Updated by Kasper Pagels about 3 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.

#26 Updated by Kasper Pagels about 3 years ago

I can see here that I am able to edit only the status, assignee and percent done. How did you limit that?

#28 Updated by ja dwa almost 3 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

#29 Updated by Mike Lees almost 3 years ago

+1

#30 Updated by Aaron Addleman almost 3 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

#31 Updated by Gokay Gok almost 3 years ago

+1

#32 Updated by Heiko Baumann almost 3 years ago

+1

#33 Updated by Dimitri Sapunou almost 3 years ago

+1

#34 Updated by Tobias Fischer over 2 years ago

+1

#35 Updated by Tiemo Vorschuetz over 2 years ago

+1

This is a great feature. Any ideas when this will be available?

#36 Updated by Bernard Steens over 2 years ago

+1

#37 Updated by Leandro Guida over 2 years ago

+1

#38 Updated by Daniele Galluccio over 2 years ago

+1

#39 Updated by Anonymous over 2 years ago

+1

#40 Updated by T. Kopetzky over 2 years ago

+1
Would be very useful for implementing roles like 'product manager'.

#41 Updated by Florent Fievez over 2 years ago

+1

#42 Updated by Rabbit Seagraves over 2 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.

#43 Updated by Markus M over 2 years ago

+1

#44 Updated by Holger Winkelmann over 2 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

#45 Updated by Terence Mill over 2 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.

#46 Updated by Harald Glock over 2 years ago

+1

#47 Updated by Terence Mill over 2 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
Related Plugins

#48 Updated by Jean-Philippe Lang over 2 years ago

Most of this request is now implemented for 2.1.0 (#703, #3521). A new screen very similar to what Terence proposed lets now configure read-only/required fields by tracker, status and role.

#49 Updated by Terence Mill over 2 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?

#50 Updated by @ go2null about 2 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.

#51 Updated by Gurvan Le Dromaguet about 2 years ago

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

#52 Updated by # And about 2 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. =)

#53 Updated by Esben Haabendal about 2 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.

#54 Updated by Abdul Halim Mat Ali about 2 years ago

I have upgraded to 2.1. Isn't the attributes hidden when you set it to read only?

#55 Updated by Brian Lindahl about 2 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.

#56 Updated by Gurvan Le Dromaguet about 2 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 !

#57 Updated by # And about 2 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?

#58 Updated by # And about 2 years ago

Gurvan Le Dromaguet, it is only solution for custom fields?

#59 Updated by Gurvan Le Dromaguet about 2 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 !

#60 Updated by # And about 2 years ago

Gurvan Le Dromaguet, OK, I'll test it today. Additionally, I create new task about hide fields on workflow ability #12005.

#61 Updated by Jean-Philippe Lang about 2 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.

#62 Updated by Steven Wong about 2 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.

#63 Updated by Heribert Steuer almost 2 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

#64 Updated by Heribert Steuer almost 2 years ago

btw, the above only applies to the "New issue" form. The issues display itself seems to work as expected.

#65 Updated by Jai prakash almost 2 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?

#66 Updated by Gurvan Le Dromaguet almost 2 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.

#67 Updated by Jai prakash almost 2 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 .

#68 Updated by Luis Serrano Aranda 8 months ago

+1

#69 Updated by Michael Sanders 3 months 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.

#70 Updated by Daniel Felix 3 months 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.

#71 Updated by Michael Sanders 3 months 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.

#72 Updated by Michael Sanders 3 months 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?

Also available in: Atom PDF