Uploaded image for project: 'Jira Cloud'
  1. Jira Cloud
  2. JSWCLOUD-5576

As a (board) administrator I'd like to access the board regardless of the filter shares

    • 13
    • 70
    • 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 Software Cloud. Using JIRA Software Server? See the corresponding suggestion.

      The visibility of Rapid Boards is based on the Shares of a filter. If a JIRA administrator shall do some changes in a Rapid Board configuration, he is only able to do so, if he is somehow included in the Share of the filter.

      This isn't the optimal in all cases.

      • When using cross-project Rapid Boards, with the filter shared with a user group, but with the user group normally not including any JIRA administrators. That means that the Rapid Board is not visible to the JIRA admin and therefore the owner of the Rapid Board is the only one who can do configure the board.
      • When the board owner or one of the admins changes the board filter to a private one, they lock all other admins out of it. Neither JIRA admins nor users that are Board administrators cannot access the board because of the missing filter share.

      That should be changes, so that a JIRA admin can see and configure all Rapid Boards, even if he is not included in the Shares of a filter. Alternatively, the "Board administrator" setting should override the filter share settings.

      Workaround

      A Jira Administrator can:

      1. Go to https://<your site name>.atlassian.net/secure/admin/filters/ViewSharedFilters.jspa and change the owner of the filter to themselves
      2. Modify and save the filter
      3. Change the owner back to the original

            [JSWCLOUD-5576] As a (board) administrator I'd like to access the board regardless of the filter shares

            Ed Bukoski added a comment -

            ZOMG please implement this.  Had to open a PS ticket just to find out which filter a user made private and locked out the rest of their team.

            Ed Bukoski added a comment - ZOMG please implement this.  Had to open a PS ticket just to find out which filter a user made private and locked out the rest of their team.

            I vote for this...

            Gary Nguyen added a comment - I vote for this...

            Actually too just being able to sort by admin name on board listing page would help tremendously.

            Karri Adkins added a comment - Actually too just being able to sort by admin name on board listing page would help tremendously.

            So is there still no way to filter for Kanban/Scrum boards by searching for a user listed as one of the board admins? It's a bit perplexing as to why this type of permission isn't granted to a Jira Administrator

            Curious on why the search option is available for "shared filters" and "shared dashboards" within Jira's settings to filter for a owner, but not as an option when searching for (either) an owner/admin for the boards? 

            Any possible workaround ideas would be greatly appreciated. Thanks.

            Jeff Gunawan added a comment - So is there still no way to filter for Kanban/Scrum boards by searching for a user listed as one of the board admins? It's a bit perplexing as to why this type of permission isn't granted to a  Jira Administrator .  Curious on why the search option is available for "shared filters" and "shared dashboards" within Jira's settings to filter for a owner, but not as an option when searching for (either) an owner/admin for the boards?  Any possible workaround ideas would be greatly appreciated. Thanks.

            Simply put, the model that is easiest for Atlassian or works in their mind is not how business works. The risk created by removing control of user names to over-comply for GDPR is not justified. This is apparent here, as well.

            The argument that it's a better security model falls flat on its face when you consider that an admin that is responsible for ensuring that a former employee/client/vendor/contractor is removed from access company confidential information. Controlling access to company assets is a valid business reason to have identity access. Non-public boards/filters/projects should have visibility by admins for the administration part.

            Atlassian, please fix the cases where admins can't control who has access to these things. To do that, admins need to be able to see and manage access. This does not mean that they need to be able to view content. This part, the filters, are one of the worst offenders of this.

            Lenard Fudala added a comment - Simply put, the model that is easiest for Atlassian or works in their mind is not how business works. The risk created by removing control of user names to over-comply for GDPR is not justified. This is apparent here, as well. The argument that it's a better security model falls flat on its face when you consider that an admin that is responsible for ensuring that a former employee/client/vendor/contractor is removed from access company confidential information. Controlling access to company assets is a valid business reason to have identity access. Non-public boards/filters/projects should have visibility by admins for the administration part. Atlassian, please fix the cases where admins can't control who has access to these things. To do that, admins need to be able to see and manage access. This does not mean that they need to be able to view content. This part, the filters, are one of the worst offenders of this.

            Please fix

            Katrine Borge added a comment - Please fix

            Same problem and surprised this has still not been even picked up - it creates a big administrative hole that shouldn't be there in enterprise-level software.

            chimera admin added a comment - Same problem and surprised this has still not been even picked up - it creates a big administrative hole that shouldn't be there in enterprise-level software.

            This is a mess and still not fixed after nearly 4 years?

            We have boards were we group different projects by meaning and every project lead is board administrator and has to change the filter when new projects are added. Every time the filter is changed, the human does not think about filter share settings (why should he?) and as a result, nobody can see the board except him!
            A very simple problem solver would be to add a note in red that when you change the filter, you shall revisit the filter permission. Or why can't the filter belong to the board or the board admin group and not the user?

            It is ridiculous that we don't get information since 2 years.

            Philipp Hundemer added a comment - This is a mess and still not fixed after nearly 4 years? We have boards were we group different projects by meaning and every project lead is board administrator and has to change the filter when new projects are added. Every time the filter is changed, the human does not think about filter share settings (why should he?) and as a result, nobody can see the board except him! A very simple problem solver would be to add a note in red that when you change the filter, you shall revisit the filter permission. Or why can't the filter belong to the board or the board admin group and not the user? It is ridiculous that we don't get information since 2 years.

            This buggy behavior is totally inconsistent, since usually an Admin (e.g. in Confluence) can see anything

            David Skreiner added a comment - This buggy behavior is totally inconsistent, since usually an Admin (e.g. in Confluence) can see anything

            Darren added a comment -

            I've just spent 2 hours on the same thing.

            We had a Board administered by the same person as the underlying JIRA Project; but one of his team could not see this Board.

            Cause: This Board's Filter was changed to a bespoke filter, and the Filter author forgot to share it out; it was only for him, and therefore not even me as JIRA Admin could find this board or Filter.

            Now.... imagine that this person then left. This means there's a LOT of hidden (to JIRA Admins) "me only" Filters and therefore Boards.

            I had to, almost ridiculously (he laughed when I asked) for him to send me a screen-clip of his Board > Configure > General > Filter so I could see, mechanically, what was going on (the Filter name was obscure).

            It shouldn't be like this for a JIRA Admin.... or should it? As JIRA Admin, people come to me as people would go to a system administrator (and we'd log on as root to get the detail we need)

            Darren added a comment - I've just spent 2 hours on the same thing. We had a Board administered by the same person as the underlying JIRA Project; but one of his team could not see this Board. Cause: This Board's Filter was changed to a bespoke filter, and the Filter author forgot to share it out; it was only for him, and therefore not even me as JIRA Admin could find this board or Filter. Now.... imagine that this person then left. This means there's a LOT of hidden (to JIRA Admins) "me only" Filters and therefore Boards. I had to, almost ridiculously (he laughed when I asked) for him to send me a screen-clip of his Board > Configure > General > Filter so I could see, mechanically, what was going on (the Filter name was obscure). It shouldn't be like this for a JIRA Admin.... or should it? As JIRA Admin, people come to me as people would go to a system administrator (and we'd log on as root to get the detail we need)

              Unassigned Unassigned
              69595d4e90f7 Holger Schimanski
              Votes:
              110 Vote for this issue
              Watchers:
              78 Start watching this issue

                Created:
                Updated: