Make issue screen readonly and display warning message

I'm writing a custom workflow to prevent edits to issues depending on certain conditions, mainly that issues of a certain Type may only be created/edited/deleted by Project Admins.

To do so I'm using an onChange rule to check that the required conditions were met, using workflow.check()

But this provides a sub-optimal user experience, because the issue appears to the user as editable, while in reality any edit will result in my custom error message.

Is there a way to run a workflow rule whenever an issue detail screen is being opened, and make it open as read-only for the current user, so that they may see at a glance that no edits are allowed? Additionally, is there a way to display a warning message on top of the issue detail screen, such as “This issue may only be edited by Project Admins”?

0
5 comments

The greyed-out view where you can't modify any values is displayed only when the Update Issue permission is missing. If you need to have some issues be read-only for a specific group of users that do have a permission to update issues in that project, then I'm afraid workflow.check() is the only viable option, even though it doesn't provide the best experience. 

Additionally, is there a way to display a warning message on top of the issue detail screen, such as “This issue may only be edited by Project Admins”?

Even though it won't be displayed on top of the screen, you can have a text field populated by a workflow whenever an issue receives a certain Type. Text fields are displayed below the standard description (and not in the custom fields section). You can also display a system-wide banner, but it's not possible to specify any conditions for its display.

1

Stanislav Dubin Do you know if there is a plan to enable workflows to specify which fields are readonly, on a issue-by-issue and user-by-user case? Is that somewhere on the roadmap?

0

Tobia Conforto Workflows cannot modify whether a certain UI item appears editable. I'm afraid there are no plans to change the underlying logic as regards project permissions, as this would further make the permissions system overcomplicated, while we want to move to a simpler system in the future. I understand that you may have valid reasons for this setup, but normally it would be solved by placing these special tasks in a separate project with a separate permission set.

Another concept that may be helpful (although not guaranteed to fit your use case) is private fields. Since they require special permissions (Read Issue Private Fields and Update Issue Private Fields), these fields will appear as non-editable to someone with a permission to read these fields without updating them. 

Combined with the Show only when setting in custom fields in your project, you might want to try out the following setup:

  • when it's an issue of a regular type, display the regular fields;
  • when it's an issue of a special type, display private fields instead.

The result may be somewhat close to what you are looking for.

1

Please sign in to leave a comment.