• 3
    • 7
    • 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.

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      As of now, there is no permission that can be applied to user(s) / group(s) on which tab can be displayed for the particular screen since users who are able to make use of the screen will be able to see all the tabs:

      As an example, you can see the following in the Create Issue screen:

      As an example, there are different departments that will access this screen with different permission. Department A only has the permission to view Tab 1 (Tab 2, Tab 3, and Tab 4 are not visible).

      On top of that, the tab can also be dynamic in a sense that when a default system field / custom field has a certain value, Tab 3 will be enabled (for an example).

        1. screen_tab_1.JPG
          screen_tab_1.JPG
          94 kB
        2. screen_tab_2.JPG
          screen_tab_2.JPG
          71 kB
        3. screen_tab_3.JPG
          screen_tab_3.JPG
          90 kB

            [JRACLOUD-34142] Issue Screen Tab Permission and Visibility

            This request talks mostly about permissions for users/groups to see tabs, but I think there's more to it when it comes to visibility. Also, how would you custom set permissions for users to see tabs? Permission schemes would not work for this as you need to define visibility based on certain conditions, so the only way I can think of this being implemented (considering the current Jira infrastructure) is through Properties on the workflow Statuses themselves - similar to what you have to do to make a screen non-editable by adding the property  jira.issue.editable = false. For instance, there could a property that sets tabs to visible = true or false by using the tab's name or number. The main use case for me would be as follows:

            • Issue has two tabs: the main one and another one for questionnaire fields (which is not visible upon issue creation)
            • If issue moves to another status through the "Respond Questionniare" transition, I present a transition screen with questions (which are custom fields)
            • User responds questions and clicks on submit and main issue view now shows a "Questionnaire" tab - which just became visible after this transition by setting issue.tab2.visible=true

            The same principle could be applied to transition screens, but the difference here is that Atlassian can provide with workflow Conditions where you can say something like "do not show tab 2 if [condition]". 

            I know this wouldn't solve the original issue described in this ticket, but it's related and definitely a big win.

            Ricardo.Gomes added a comment - This request talks mostly about permissions for users/groups to see tabs, but I think there's more to it when it comes to visibility. Also, how would you custom set permissions for users to see tabs? Permission schemes would not work for this as you need to define visibility based on certain conditions, so the only way I can think of this being implemented (considering the current Jira infrastructure) is through Properties on the workflow Statuses themselves - similar to what you have to do to make a screen non-editable by adding the property   jira.issue.editable = false. For instance, there could a property that sets tabs to visible = true or false by using the tab's name or number. The main use case for me would be as follows: Issue has two tabs: the main one and another one for questionnaire fields (which is not visible upon issue creation) If issue moves to another status through the "Respond Questionniare" transition, I present a transition screen with questions (which are custom fields) User responds questions and clicks on submit and main issue view now shows a "Questionnaire" tab - which just became visible after this transition by setting issue.tab2.visible=true The same principle could be applied to transition screens, but the difference here is that Atlassian can provide with workflow Conditions where you can say something like " do not show tab 2 if [condition] ".  I know this wouldn't solve the original issue described in this ticket, but it's related and definitely a big win.

            Emanuel Y added a comment -

            The noted request would be a major win. However, I see the original request was made back in 2013. Any idea of the work effort needed to tie permissions to the Screen Tab? I'm curious if you could reuse code to assist with the update. 

            Emanuel Y added a comment - The noted request would be a major win. However, I see the original request was made back in 2013. Any idea of the work effort needed to tie permissions to the Screen Tab? I'm curious if you could reuse code to assist with the update. 

            Amy Lee added a comment - - edited

            I need this functionality as well. Being able to control which tabs can be seen by a given user would be ideal for my use case.

            +1

            Amy Lee added a comment - - edited I need this functionality as well. Being able to control which tabs can be seen by a given user would be ideal for my use case. +1

            This is exactly the functionality I'm looking for right now! So much easier and efficient than duplicating screens and showing a screen based on user permissions
            +1

            Jirrod Glynn added a comment - This is exactly the functionality I'm looking for right now! So much easier and efficient than duplicating screens and showing a screen based on user permissions +1

            +1

            +1
            We need this feature very much.

            Ivan Kulchytskyi added a comment - +1 We need this feature very much.

              Unassigned Unassigned
              adanial Ahmad Danial (Inactive)
              Votes:
              24 Vote for this issue
              Watchers:
              19 Start watching this issue

                Created:
                Updated: