Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-74697

Expose Project Issue layout for new issue view via the REST API

    • 90
    • 13
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Summary

      Currently, it is not possible to automate or make changes to the issue layout using the REST API.

      Suggestion

      Expose the Jira Issue layout configuration for the new issue view via the Jira Cloud REST API to allow automations making it possible to edit issue layouts in bulk.

            [JRACLOUD-74697] Expose Project Issue layout for new issue view via the REST API

            "Even if you share a screen between projects, the layout is still per-project. I have 60+ projects using the same screen, but all separate layouts. If I'm missing something, please let me know.

            Ultimately layouts should be manageable like any other scheme and available through the API.

            In any case, this feature would be really nice to have. +100"

            Same here

            Thierry BLOCH added a comment - "Even if you share a screen between projects, the layout is still per-project. I have 60+ projects using the same screen, but all separate layouts. If I'm missing something, please let me know. Ultimately layouts should be manageable like any other scheme and available through the API. In any case, this feature would be really nice to have. +100" Same here

            David Berclaz (Apwide) added a comment - - edited

            I'm not sure to understand why we cannot update the issue layout through the Rest API.

            We need this implementation for one of our Forge apps, in order to display custom fields in the middle of the screen.

            David Berclaz (Apwide) added a comment - - edited I'm not sure to understand why we cannot update the issue layout through the Rest API. We need this implementation for one of our Forge apps, in order to display custom fields in the middle of the screen.

            Who's still here in 2025 ?

             

            This would be great for all users relying on automated tools to manage multiple projects...

            Magnus Anderssen added a comment - Who's still here in 2025 ?   This would be great for all users relying on automated tools to manage multiple projects...

            1eec8be160e8 I don't think your suggestion below works.

            Even if you share a screen between projects, the layout is still per-project. I have 60+ projects using the same screen, but all separate layouts. If I'm missing something, please let me know.

            Ultimately layouts should be manageable like any other scheme and available through the API.

            In any case, this feature would be really nice to have. +100

            Chris Garstin added a comment - 1eec8be160e8 I don't think your suggestion below works. Even if you share a screen between projects, the layout is still per-project. I have 60+ projects using the same screen, but all separate layouts. If I'm missing something, please let me know. Ultimately layouts should be manageable like any other scheme and available through the API. In any case, this feature would be really nice to have. +100

            Is this something that is on the radar? We could really do with this functionality, as the project configuration process is a bit of a blocker with our wider teams.

            Niamh Hogan added a comment - Is this something that is on the radar? We could really do with this functionality, as the project configuration process is a bit of a blocker with our wider teams.

            Any News on it?

            Rishabh Prashar added a comment - Any News on it?

            Florian Royer added a comment - - edited

            Hello, community,

            For your information, we have put in place a strategy internally and with our customers, and that could help you too.

            Merge the screens

            Try to merge your screens as much as possible to limit the number of layouts.

            Don't create one screen for each issue type or for each "process", but a common screen that will gather all the fields in the screens, and leverage Field Contexts and Field configuration to hide the fields from the screens.

            E.g: I have the field "Current behavior vs expected" on issuetype bug. I hide this field in field configuration for the issue type "Story" (one field configuration per issue type makes everything super scalable), and I make it mandatory for the "Bug" issue type. Additionnally, to avoid any appearance of the field, I select the issue type "Bug" in the context of this field.

            One recommendation though: have one common screen for each issue hierarchy level.

            One for Epic, one for standard tasks, and one for sub-tasks.

            At the end, you should have only 3 layouts to configure, therefore.

             


            Leverage the tabs on screens

            You can create tabs that won't be configured in the issue layout.

            That is a very good workaround for sub-tasks for JSM projects by the way as there are still no layouts definition possible for sub-tasks as they don't have Request types: JSDCLOUD-1422 ... but that's another story...

            By creating tabs, you limit the impacts of the issue layout on your screen and what the user sees.

            So, it's allowing you to keep your fields untouched even if there is no layout configured.

             


            Template to store your layouts

            1. Creates an empty project that will be your template and accessible only by the admin. You put your original layout configs there. That way, if a product manager or a project lead changes the layouts on its own project, it won't affect the other, and you can still restore the original layouts.
            2. There are a couple of advantages by having an empty project to store the definition and layouts.

             


            Inform the admin with automation

            Then, you put in place a JIRA automation to inform the Jira admin when a new project is created. So, the Jira admin has to go to the Template project and copy the 3 layouts to the new created project, it's literally a 2 minutes thing to do. We put in place an "on-event" automation, triggered when a new project is created, and create a new task in our SYSADMIN projects, then send a Slack also to the Admin channel. => impossible to miss it

             

            I know that it's not ideal, but as Atlassian is not responsive and doesn't seem to consider their customers as they should, we have to find solutions.

            We are still eager to have this to be implemented in OOTB, to avoid additional work for our team, so Atlassian, please raise it up!
             
             
             
             
             
             

            Florian Royer added a comment - - edited Hello, community, For your information, we have put in place a strategy internally and with our customers, and that could help you too. Merge the screens Try to merge your screens as much as possible to limit the number of layouts. Don't create one screen for each issue type or for each "process", but a common screen that will gather all the fields in the screens, and leverage Field Contexts and Field configuration to hide the fields from the screens. E.g: I have the field "Current behavior vs expected" on issuetype bug. I hide this field in field configuration for the issue type "Story" (one field configuration per issue type makes everything super scalable), and I make it mandatory for the "Bug" issue type. Additionnally, to avoid any appearance of the field, I select the issue type "Bug" in the context of this field. One recommendation though: have one common screen for each issue hierarchy level. One for Epic, one for standard tasks, and one for sub-tasks. At the end, you should have only 3 layouts to configure, therefore.   Leverage the tabs on screens You can create tabs that won't be configured in the issue layout. That is a very good workaround for sub-tasks for JSM projects by the way as there are still no layouts definition possible for sub-tasks as they don't have Request types: JSDCLOUD-1422 ... but that's another story... By creating tabs, you limit the impacts of the issue layout on your screen and what the user sees. So, it's allowing you to keep your fields untouched even if there is no layout configured.   Template to store your layouts Creates an empty project that will be your template and accessible only by the admin. You put your original layout configs there. That way, if a product manager or a project lead changes the layouts on its own project, it won't affect the other, and you can still restore the original layouts. There are a couple of advantages by having an empty project to store the definition and layouts.   Inform the admin with automation Then, you put in place a JIRA automation to inform the Jira admin when a new project is created. So, the Jira admin has to go to the Template project and copy the 3 layouts to the new created project, it's literally a 2 minutes thing to do. We put in place an "on-event" automation, triggered when a new project is created, and create a new task in our SYSADMIN projects, then send a Slack also to the Admin channel. => impossible to miss it   I know that it's not ideal, but as Atlassian is not responsive and doesn't seem to consider their customers as they should, we have to find solutions. We are still eager to have this to be implemented in OOTB, to avoid additional work for our team, so Atlassian, please raise it up!            

            Same here: at one of our customers, automating Jira project creation is a crucial component for their plan of starting to use Jira outside software development departments. We have a solution in place, but issue layouts would currently need to be set up manually. Like Florian Royer's case, this is not scalable for them.

             

            Please fix this!

            Jens Bannmann added a comment - Same here: at one of our customers, automating Jira project creation is a crucial component for their plan of starting to use Jira outside software development departments. We have a solution in place, but issue layouts would currently need to be set up manually. Like Florian Royer's case, this is not scalable for them.   Please fix this!

            Atlassian, news about this ?

            it's need to fully automate the creation of our projects... we have 5 new projects on the daily basic, it takes to much time...
             
             
             

            Florian Royer added a comment - Atlassian, news about this ? it's need to fully automate the creation of our projects... we have 5 new projects on the daily basic, it takes to much time...      

            This would be incredibly helpful for automating the last few manual steps of project creation. This would also help ensure projects are formatted consistently. Currently I am not aware of a way to check project layouts without loading and visually comparing each one, or re-copying the layout. If there are any workarounds or solutions in the meantime, please post. 

            David Pezet added a comment - This would be incredibly helpful for automating the last few manual steps of project creation. This would also help ensure projects are formatted consistently. Currently I am not aware of a way to check project layouts without loading and visually comparing each one, or re-copying the layout. If there are any workarounds or solutions in the meantime, please post. 

              Unassigned Unassigned
              jlong@atlassian.com Jared Long
              Votes:
              100 Vote for this issue
              Watchers:
              56 Start watching this issue

                Created:
                Updated: