RTC Read-Only Preconditions inconsitent with Status Field
We are are trying to make the status field "Read-Only" on the UI for some work item types. This is working well for all attributes except the Status field.
We have tried 2 mechanisms:
Read-Only Attributes for Type and State and Read-Only Attributes for Conditions where the "condition is the name of Javascript implemented in the Attribute Customization Conditions and simply returns True or False by Work item type.
In both cases, when opening a work item, the behavior is correct. However, when switching from work item to work item using the links, all attributes behave correctly except the status field.
When switching from a work item where the status is editable, back to a work item where the status is not editable (by role), the status field remains editable. All other fields instantaneously reflect the proper behavior. Sometimes, the status will repaint to not-editable in a few seconds, sometimes it does not. Clicking refresh will provide the correct behavior.
The contrary is also true. If switching from a work item that has the status read-only to another work item that has the status read-write, the status property stays read most of the time. All other fields immediately reflect the correct behavior. The user must click the refresh button to get the proper behavior of the status field.
Has anyone else had this problem and found a consistent way to make the status field behave properly?
We have tried 2 mechanisms:
Read-Only Attributes for Type and State and Read-Only Attributes for Conditions where the "condition is the name of Javascript implemented in the Attribute Customization Conditions and simply returns True or False by Work item type.
In both cases, when opening a work item, the behavior is correct. However, when switching from work item to work item using the links, all attributes behave correctly except the status field.
When switching from a work item where the status is editable, back to a work item where the status is not editable (by role), the status field remains editable. All other fields instantaneously reflect the proper behavior. Sometimes, the status will repaint to not-editable in a few seconds, sometimes it does not. Clicking refresh will provide the correct behavior.
The contrary is also true. If switching from a work item that has the status read-only to another work item that has the status read-write, the status property stays read most of the time. All other fields immediately reflect the correct behavior. The user must click the refresh button to get the proper behavior of the status field.
Has anyone else had this problem and found a consistent way to make the status field behave properly?
3 answers
Hi Steve,
Just wanted to share a different approach here. If your goal is to prevent users from transitioning work items from one state to another, you can revoke their permissions to trigger a specific workflow action, based on the role. The status field will remain editable, but the user will get an error message when saving the WI.
Just wanted to share a different approach here. If your goal is to prevent users from transitioning work items from one state to another, you can revoke their permissions to trigger a specific workflow action, based on the role. The status field will remain editable, but the user will get an error message when saving the WI.
After reading this again, I don't think you even should use the read only conditions to try to make the status field read only. One reason is that the status attribute is a mix between showing a state and the available actions.
I haven't really looked at this, but I know that the built in operational behavior for read only and required attributes actually calculates the current state for the condition based on the selected action. So you might have to take into consideration that if you select an action the state of the work item really is the one reached after the transition and the condition would now have different results.
You can look at some related code in https://rsjazz.wordpress.com/2015/06/19/a-custom-condition-to-make-attributes-required-or-read-only-by-role/
I haven't really looked at this, but I know that the built in operational behavior for read only and required attributes actually calculates the current state for the condition based on the selected action. So you might have to take into consideration that if you select an action the state of the work item really is the one reached after the transition and the condition would now have different results.
You can look at some related code in https://rsjazz.wordpress.com/2015/06/19/a-custom-condition-to-make-attributes-required-or-read-only-by-role/