Feature #8050

Mightful workflow field enhancement: visible, read only and mandatory

Added by Terence Mill about 3 years ago. Updated about 1 month 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] almost 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] almost 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] almost 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 almost 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 almost 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] almost 3 years ago

Terence Mill wrote:

See the wire frame demo

good mockup

#7 Updated by Terence Mill almost 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 almost 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 almost 3 years ago

Screeners of the demo

#10 Updated by Terence Mill almost 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 almost 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 almost 3 years ago

  • Assignee set to Terence Mill

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

#13 Updated by Terence Mill almost 3 years ago

  • Assignee deleted (Terence Mill)

#14 Updated by Brian Heasley almost 3 years ago

+1

#16 Updated by Seth Sandler over 2 years ago

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

#17 Updated by Terence Mill over 2 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 2 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 over 2 years ago

+1

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

#20 Updated by Sławomir Kaimakami over 2 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 over 2 years ago

+1

#22 Updated by Pierluigi Soana over 2 years ago

+1 Very useful

#23 Updated by Darko Lombardo over 2 years ago

+1 A Must for usable Workflows

#25 Updated by Kasper Pagels over 2 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 over 2 years ago

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

#27 Updated by Sébastien Gripon over 2 years ago

+1

#28 Updated by ja dwa over 2 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 over 2 years ago

+1

#30 Updated by Aaron Addleman over 2 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 over 2 years ago

+1

#32 Updated by Heiko Baumann over 2 years ago

+1

#33 Updated by Dimitri Sapunou over 2 years ago

+1

#34 Updated by Tobias Fischer about 2 years ago

+1

#35 Updated by Tiemo Vorschuetz about 2 years ago

+1

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

#36 Updated by Bernard Steens about 2 years ago

+1

#37 Updated by Leandro Guida about 2 years ago

+1

#38 Updated by Daniele Galluccio about 2 years ago

+1

#39 Updated by Rene Schmidt about 2 years ago

+1

#40 Updated by T. Kopetzky about 2 years ago

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

#41 Updated by Florent Fievez almost 2 years ago

+1

#42 Updated by Rabbit Seagraves almost 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 almost 2 years ago

+1

#44 Updated by Holger Winkelmann almost 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 almost 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 almost 2 years ago

+1

#47 Updated by Terence Mill almost 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 almost 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 almost 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 James over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

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

#55 Updated by Brian Lindahl over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

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

#59 Updated by Gurvan Le Dromaguet over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 .

Also available in: Atom PDF