How to define a field specific behavior in a specific screen

Question

First, you should know that I attend to configure JIRA for a industrial avionics development driven by technical facts (issues for Atlassian). The process is an Agile mix with our practices.

The philosophy of JIRA use for us is to offer for all users (except a admin one, all have the same right), interfaces (screens related to the transitions) that are compliant with their tasks and project data to see and set by them at the moment of the life cycle of development.

Depending of the current development phases, some issue data are not already known or are not meant to be entered, such for instance the report of modifications when it exists an analysis phase about what can be done.

To alleviate fields presentation in the screen dedicated to the current transition, it will be very interesting to hide a field that are not meant to be read or entered in the screen associated to the transition related to the phase.

Also, it will be interesting to lock a field in particular screen/s to prohibit involuntary modifications during the phase.

I do not find how to do this, since, the hidden/show or required/optional attributes are associated to a issue type or a project ... and there are not read/edit attributes.

Thank you for your attention,

Dominique Rivière

Responsable Amélioration Continue Produits en Service

Thales Avionics

RIVIERE Dominique · Answer

I see your point/s.

My point:

“Fields cannot be rendered as read-only on these screens because there is no mechanism for you to tell JIRA that when you are editing, you don't really want to edit the field.”

A screen could be designed to edit part but not all data presented, isn't it ?

We need some fields in addition to key or other protected fields, that can be read-only depending the screen to which they are attached.

Let's says it is about un handful of fields we are talking about, so long for the screen complexity.

We want JIRA issues usage to map an engineering process and not only to be used to assign and report modifications. I am convinced it can be done and JIRA is good choice for such a purpose ... since.

In our vision, users *have not already decided to make the change to the issue* at least for all the fields when they will log to their JIRA, they will be logged almost permanently in their tool.

After, it is not because JIRA does not currently offer the facility that we cannot ask for or hope some adds-on fulfill the need or far better, JIRA next version will integrate such an evolution.

Nic Brough -Adaptavist- · Answer

In a very roundabout way, you did - I had not picked it up because it is buried and unclear.

JIRA fields on transition and edit screens are always rendered in "edit" mode because the screen is there to allow the user to edit the issue.

Fields cannot be rendered as read-only on these screens because there is no mechanism for you to tell JIRA that when you are editing, you don't really want to edit the field.

This makes a lot of sense in terms of user interaction - to get to a transition field, your user has *already decided to make the change to the issue*.  Showing them the fields they've based that decision on again makes the screen more complex and slows them down, while not giving them any more information than they've already made the decision on.

RIVIERE Dominique · Answer

Did I write we want to display fields even if they are not to be modified or entered ?

In fact I should do it because it is what we want : to present all data need, the already set ones as well the to be updated and to be entered ones, for the task related to complete the technical fact at a moment particular of the development life cycle in the associated screen.

In our planned JIRA configuration, issue transitions map phase transitions, screen data have to map data to be set and reviewed.

So we want screens that map phases, screens that present data useful for the phase tasks, data required to be entered, update or reviewed. So fields shall be readable /editable, required/optional, hidden/shown.

For instance, during the “correction phase”, a list of verification procedures to run is finalized (established firstly during estimate phase) thanks to the impact analysis performed from the knowledge of the modified components and interfaces.

In the next phase, the verifier reports verification procedures results. To prepare the next transition, he have to check the verification procedure effectively run versus the verification procedures planned.

Best regards

Dominique Rivière