Redmine - Feature #8050
Mightful workflow field enhancement: visible, read only and mandatory
2011-04-03 02:15 - Terence Mill

ステータス:

Closed

開始日:

優先度:

Normal

期日:

担当者:
カテゴリ:

Issues workflow

2011-04-03

進捗率:

0%

予定工数:

0.00時間対象バージョン:Resolution:
説明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 onlyused in development stage by developers) or a status can only be changed if a certain field is set (field is mandatory for statuschange 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 statusin 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 ;) )関連するチケット:
関連している Redmine - Feature #703: Configurable required fiel...

Closed2008-02-21

関連している Redmine - Patch #7444: Patch for improved issue ed...

Closed2011-01-25

関連している Redmine - Feature #2539: New project setting: mand...

New

2009-01-19

関連している Redmine - Feature #9700: Allow to configure the vi...

Closed関連している Redmine - Feature #9736: custom field visibility b...

Closed関連している Redmine - Feature #3521: Permissions for roles to ...

Closed2009-06-22

関連している Redmine - Feature #2500: configure custom fields a...

Closed2009-01-13

関連している Redmine - Feature #12005: Mightful workflow field ...

New

関連している Redmine - Feature #393: Role that can't assign a t...

Closed関連している Redmine - Feature #4707: private fields

New

2010-02-01

関連している Redmine - Feature #8313: Restrict Assignee List by...

New

2011-05-06

関連している Redmine - Feature #10162: require notes on specifi...

New

次のチケットが重複 Redmine - Feature #11329: Private custom fields

Closed履歴#1 - 2011-05-07 20:46 - pasquale [:dedalus]+1
fundamental feature for redmine: in real world more fields are only for developers, others for reporter...
#2 - 2011-05-08 13:03 - pasquale [:dedalus]
Terence Mill wrote:2024-09-29

1/11

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 - 2011-05-08 13:12 - pasquale [:dedalus]
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 - 2011-05-08 14:33 - Terence Mill#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 - 2011-05-09 17:28 - Terence MillI 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 thechoosen 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 - 2011-05-09 17:31 - pasquale [:dedalus]
Terence Mill wrote:
See the wire frame demo

good mockup#7 - 2011-05-10 20:51 - Terence MillI 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 theissue 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 fieldmandatory - 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.

2024-09-29

2/11

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 oncolumn 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 atleast order in the two column layout could be configurable with this new control. Number in the drop-down equates the position top-down in thelayout.
Any sugesstions and contrbutions to change or add this demo as visual specification are welcome.
#8 - 2011-05-18 15:48 - Terence Mill

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 oncolumn 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-downin 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 fieldshall be showed. See Single column custom fields#9 - 2011-05-18 15:56 - Terence Mill- ファイル Screenshot0.jpg を追加- ファイル Screenshot1.jpg を追加- ファイル Screenshot2.jpg を追加
Screeners of the demo
Screenshot0.jpg
Screenshot1.jpg
Screenshot2.jpg#10 - 2011-05-18 16:19 - Terence Mill
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 theseassigment, 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 thefield 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

Status1

4

Priority

1

5

Assignee

16Category

1

7Affected version

1

8

Start date2

4

Due date

2

5

Estimated time Hours

2

6

%Done

2

7

Resolution282024-09-29

3/11

Files1

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 ofcolumns 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 - 2011-06-27 16:28 - Maarten Klerk
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 - 2011-06-28 22:02 - Benjamin Bohn
- 担当者 を Terence Mill にセット
When will this feature be released? Or is a plugin available?
#13 - 2011-06-28 23:28 - Terence Mill- 担当者 を削除 (Terence Mill)#14 - 2011-07-13 21:43 - Brian Heasley+1#15 - 2011-07-23 22:49 - Christian Köwing
+1#16 - 2011-07-30 23:06 - Seth Sandler
Is this available somewhere? Is it just a mockup or is this actually working code?
#17 - 2011-07-31 15:10 - Terence MillIts 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 - 2011-07-31 19:51 - Seth Sandler
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 - 2011-09-09 11:31 - Mathieu Rochette+1
we'd like to prevent non-member to set assigned to and priority#20 - 2011-09-17 18:25 - Sławomir Kaimakami+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 - 2011-09-20 09:48 - Tony Marschall+1#22 - 2011-09-20 11:51 - Pierluigi Soana+1 Very useful#23 - 2011-09-29 08:42 - Darko Lombardo

2024-09-29

4/11

+1 A Must for usable Workflows#24 - 2011-10-28 12:08 - Gurvan Le Dromaguet+1#25 - 2011-10-29 09:52 - Kasper Pagels+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 - 2011-10-29 09:58 - Kasper Pagels
I can see here that I am able to edit only the status, assignee and percent done. How did you limit that?
#27 - 2011-11-03 09:35 - Sébastien Gripon+1#28 - 2011-11-17 16:50 - ja dwa
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 - 2011-11-22 20:59 - Mike Lees
+1
#30 - 2011-12-02 19:39 - Aaron Addleman
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 - 2012-01-06 12:49 - Gokay Gok+1#32 - 2012-01-23 13:35 - The 2nd+1#33 - 2012-01-24 10:57 - Dimitri Sapunou+1#34 - 2012-02-08 12:45 - Tobias Fischer+1#35 - 2012-02-15 12:59 - Tiemo Vorschuetz+1This is a great feature. Any ideas when this will be available?
#36 - 2012-02-27 09:31 - Bernard Steens+1#37 - 2012-03-06 19:41 - Leandro Guida

2024-09-29

5/11

+1
#38 - 2012-03-06 21:57 - Daniele Galluccio+1#39 - 2012-03-07 08:07 - 匿名ユーザー+1#40 - 2012-03-08 16:57 - 匿名ユーザー+1
Would be very useful for implementing roles like 'product manager'.
#41 - 2012-04-27 13:22 - Florent Fievez+1#42 - 2012-05-01 21:05 - Rabbit Seagraves
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 - 2012-05-01 21:53 - Markus M+1#44 - 2012-05-19 22:05 - Holger Winkelmann
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 evena more flexible way#45 - 2012-05-20 00:52 - Terence MillThe function "assign issue to roles" is not part of this feature request.
This feature request is sadly not on the roadmap so far.
#46 - 2012-05-20 10:39 - Harald Glock+1#47 - 2012-06-02 12:43 - Terence MillAll 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
Thread Require assigned̲to field for tickets set default assignee
Thread Required fields depending on status
Related Plugins
Redmine-Fields-permissions and Forks
Redmine hide assigned to field with role permissions plugin
Show/hide assigned to, Start date, Due date, Estimated hours,Priority

2024-09-29

6/11

#48 - 2012-07-15 18:26 - Jean-Philippe Lang
- ファイル workflow̲permissions.png を追加
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 - 2012-07-16 10:22 - Terence Mill
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 - 2012-08-30 20:12 - @ go2null
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 - 2012-09-03 16:05 - Gurvan Le Dromaguet- ファイル NoRedStarForMandatoryField.png を追加
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

2024-09-29

7/11

For now, I am trying to code a patch for the hidden attribute capability#52 - 2012-09-04 19:33 - # And
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 - 2012-09-21 12:48 - Esben Haabendal
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 - 2012-09-22 03:38 - Abdul Halim Mat Ali
I have upgraded to 2.1. Isn't the attributes hidden when you set it to read only?
#55 - 2012-09-24 07:04 - Brian Lindahl
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 canprevent 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 issues2) authored issues3) assigned issues
As such, patch #7444 is still necessary.
#56 - 2012-09-28 12:29 - Gurvan Le Dromaguet- ファイル workflow̲hidden̲field.diff を追加
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.

2024-09-29

8/11

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 - 2012-10-01 23:59 - # And
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 - 2012-10-02 00:03 - # And
Gurvan Le Dromaguet, it is only solution for custom fields?
#59 - 2012-10-02 11:27 - Gurvan Le Dromaguet- ファイル workflow̲hidden̲field̲v0.03.diff を追加
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 - 2012-10-02 12:05 - # And
Gurvan Le Dromaguet, OK, I'll test it today. Additionally, I create new task about hide fields on workflow ability #12005.
#61 - 2012-10-27 10:54 - Jean-Philippe Lang- ステータス を New から Closed に変更
I'm closing it in favour of #12005 now that the read-only/required part of this request is implemented.
#62 - 2012-10-31 04:48 - Steven Wong
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 - 2012-11-20 12:07 - Heribert Steuer
Hello,
first of all thanks alot for this patch, helps alot to cover our usecases!

2024-09-29

9/11

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 resultsof 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 - 2012-11-20 12:21 - Heribert Steuer
btw, the above only applies to the "New issue" form. The issues display itself seems to work as expected.
#65 - 2013-01-21 10:21 - Jai prakash
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 thehidden 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 - 2013-01-21 10:32 - Gurvan Le Dromaguet
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 forediting 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 - 2013-01-21 10:49 - Jai prakashjai 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 forediting too right?

OOPS sorry my bad . Please ignore this . I see that #12005 has it resolved .
#68 - 2014-03-06 11:10 - Luis Serrano Aranda+1#69 - 2014-07-24 04:22 - Michael Sanders
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 uponcreation, but show them when the issue is created and when the user is editing it.
#70 - 2014-07-24 09:35 - Daniel Felix
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 - 2014-07-24 15:10 - Michael Sanders
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 - 2014-07-24 16:50 - Michael Sanders
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.

2024-09-29

10/11

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?
#73 - 2019-05-16 05:46 - Sky Stalker
https://github.com/Neticoa/redmine̲workflow̲hidden̲fields
http://www.redmine.org/plugins/redmine̲workflow̲hidden̲fields
this plugin can solve the problem

ファイル
Screenshot0.jpg

23.1 KB

2011-05-18

Terence Mill

Screenshot1.jpg

65.3 KB

2011-05-18

Terence Mill

Screenshot2.jpg

344 KB

2011-05-18

Terence Mill

workflow̲permissions.png

13.7 KB

2012-07-15

Jean-Philippe Lang

NoRedStarForMandatoryField.png

49.2 KB

2012-09-03

Gurvan Le Dromaguet

workflow̲hidden̲field.diff

4.79 KB

2012-09-28

Gurvan Le Dromaguet

workflow̲hidden̲field̲v0.03.diff

8.73 KB

2012-10-02

Gurvan Le Dromaguet

2024-09-29

11/11