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,
Responsable Amélioration Continue Produits en Service
You need to be looking at screens rather than fields. Screens are lists of fields that are shown to the user at certain times.
JIRA doesn't have "lock" fields on transitions. If you don't want someone to modify a field during a transition, then you set up the transition with a screen that does not include the field. (To put that in a more positive way: When you define a transition, give it a screen that only includes the fields you want to let them change)
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.
I see your point/s.
“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.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs