Redmine

+1

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

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?

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"

#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"

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

Terence Mill wrote:

See the wire frame demo

good mockup

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.

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

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

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.

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'.

+1

+1

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

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?

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

+1

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

+1 +1 +1
We need this so much...
For me and my company this is the most important functionality that is missing in Redmine.

+1

+1 Very useful

+1 A Must for usable Workflows

+1

+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.

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

+1

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

+1

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

+1

+1

+1

+1

+1

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

+1

+1

+1

+1

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

+1

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.

+1

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

The function "assign issue to roles" is not part of this feature request.

This feature request is sadly not on the roadmap so far.

+1

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

• Thread Require assigned_to field for tickets set default assignee
• Thread Required fields depending on status

• 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

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?

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.

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. =)

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 have upgraded to 2.1. Isn't the attributes hidden when you set it to read only?

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.

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?

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

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

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.

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

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

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?

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.

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 .

+1

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.

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.

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.

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?

https://github.com/Neticoa/redmine_workflow_hidden_fields
http://www.redmine.org/plugins/redmine_workflow_hidden_fields
this plugin can solve the problem