Creating a customs hidden fields in all project to store data for JQL

[omerro]

Context

• I have a site with many projects 
• Different projects use different screen schemes and filed configuration schemes. 

Goal

• Store the date an issue moved from a specific project to any other project in a custom field (date picker) 
• Use the custom field in a JQL to extract insights

Process

• Created the custom field 
• Connected the custom field to an automation (rule) so that the custom field will be updated with date of the day the issue moved from a specific project to any other project.

Question

• I want my custom filed to be hidden across all project and schemes - how do I do that?

[sanam malleswari]

Hi @omerro ,

Please restrict the custom field context to only single project that's require to appear.
In the field configurations, there is option to HIDE the custom field. 
if anyone tried to use that custom field, it won't work and it will be hidden always.

The automation rule will still be able to update the hidden field since it doesn't rely on visibility in the UI.

Thanks,
Sanam

[omerro]

Hey @sanam malleswari 

1. By doing this will the data be saved even if the issues is in a project that is not in the context?
2. What about associated screens? Should I only connect the custom filed to a single project without connecting to any screens?  

[sanam malleswari]

@omerro ,

1. Will the data be saved even if the issue is in a project that is not in the context?No, the data will not be saved if the issue is in a project that is not in the custom field’s context. The field needs to be in the field context of the project for the data to be stored.

2. Should I only connect the custom field to a single project without connecting it to any screens?

you can connect the custom field to a specific project or projects without associating it with any screens.

[Marc - Devoteam]

Hi @omerro 

This can be done, but only in company managed projects

There are three things a field needs to be set for if you want to use it:

• The field configuration can hide fields, but they still exist when hidden, and may contain data.
• The field has to be on a screen to be used, but when it is not, it is the same as field config.
• The context of a custom field is where a field exists for an issue or not. A field must have a context for there be a place to put any data that goes into it.
  The problem here is that Automation respects the edit screen for an issue. If your field is not on it, it can't edit it. But that does not apply to hidden fields.

So, yes, without other apps, your only option is to add the field to all the screens, and then hide it in all the field configurations.

[omerro]

@Marc - Devoteam What about not hiding but restricting the permission to change the data? 

Can this be done in an easier way?

[Marc - Devoteam]

Hi @omerro 

The are no field restriction option in Jira.

As mentioned, when. you want to use automation the field needs to be on the edit screen as a minimum requirement.

Fields not on screens can't be amended by an automation rule

[omerro]

On the edit screen of all screen schemes and projects? 

[Marc - Devoteam]

Hi @omerro 

That depends on when the automation triggers, on issue creation or further along the issues workflow.

If it's only on the lifespan after creation ,then only the edit screen should have the field.

[Marc - Devoteam]

Hi @omerro 

On all edit screens of all screens schemes on all projects and then in all field configurations oof all projects, hide the field.

Then automation can use the field, but it won't be visible.

[Fazila Ashraf]

Hi @omerro 

Any custom field that is not in the screens of the project will not be visible on the ticket itself. So remove the field from all associated screens.

[omerro]

If I do this will the data still be stored and will my automation work?

[Marc - Devoteam]

Hi @Fazila Ashraf 

@omerro wants to use automation, hiding from screens is then not an option. As automation requires the field to be on at least the edit screen used, related to the issue types used on the projects

[Fazila Ashraf]

@Marc - Devoteam @omerro , With automation, you can edit an issue value in automation while not having them on the screen. 

Did you try it? Did it not work for you?

[Marc - Devoteam]

Yes,

If the field ins on the screen and hidden a field config you can use it in automation.

And if it a scheduled action and on having an action like transition, move, but here the requirement is on moving an issue.

[Fazila Ashraf]

@Marc - Devoteam , Sorry. I do not understand what you mean but i tested for the given scenario and the below automation worked with out the 'Move date' field in screens. The value was reportable in issue navigator.

[omerro]

@Fazila Ashraf and the custom filed is not connected to any screen schemes? What is the context of the custom field?

[Fazila Ashraf]

@omerro , You can have it as an open default context. Not restricted.

Basically have it available for all the projects where you would like to use the field. 

[Fazila Ashraf]

And yes, not in the screens / screen schemes.

That is my key answer.  Use the field normally in automation but remove it from the screens to make it not available in the issue's views but still available for reporting.