Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restricting and unrestricting access to a table results in the DB-level permission still being "Granular" #20436

Closed
noahmoss opened this issue Feb 11, 2022 · 5 comments · Fixed by #21571
Assignees
Labels
Administration/Permissions Collection or Data permissions Priority:P2 Average run of the mill bug .Reproduced Issues reproduced in test (usually Cypress) Type:Bug Product defects
Milestone

Comments

@noahmoss
Copy link
Member

Describe the bug
If you restrict data access to a single table in a database, and then change it back to unrestricted, the data access level in the UI for the entire database will display as "Granular" even though access to all the tables is unrestricted.

To Reproduce
Steps to reproduce the behavior:

  1. On a fresh instance of Metabase, go Admin -> Permissions
  2. Click on 'All Users'
  3. Click on 'Sample Database'
  4. Change the data access for a single table to 'No self-service', and save
  5. Change the data access for that table back to 'Unrestricted', and save
  6. Click on 'Sample Database' again. See that the data access is displayed as 'Granular', even though all tables have unrestricted access.

Expected behavior
Data access to the DB should go back to 'Unrestricted'

Information about your Metabase Installation:
Current master

Severity
Minor, but probably blocking some work for an upcoming project so serious in that regard.

@noahmoss noahmoss added Type:Bug Product defects .Needs Triage labels Feb 11, 2022
@noahmoss
Copy link
Member Author

Seems like this is the same as #16253, closing in favor of that

@flamber
Copy link
Contributor

flamber commented Feb 11, 2022

Quite sure it's not a duplicate of #16253, since that's specifically about Sandboxing. Sounds a lot more like #17764

@noahmoss
Copy link
Member Author

It's not a duplicate of #16253 from a user point of view but I'm pretty sure it has the same root cause on the backend.

@camsaul said he can fix that one quickly, so I'll reopen this until we verify that fixing that issue fixes this one as well.

@noahmoss noahmoss reopened this Feb 11, 2022
@flamber flamber added Administration/Permissions Collection or Data permissions Priority:P2 Average run of the mill bug and removed .Needs Triage labels Feb 11, 2022
@alxnddr alxnddr self-assigned this Feb 11, 2022
@noahmoss
Copy link
Member Author

@alxnddr This is actually a backend bug (i.e. it should be replacing the individual permission paths for each table with a general one for the DB). As far as I can tell, the frontend will do the right thing when the backend is fixed.

@noahmoss
Copy link
Member Author

@alxnddr I take it back, this does seem to be a frontend issue. On the second request, the frontend is sending a graph that looks like this (in part):

        "data": {
          "schemas": {
            "PUBLIC": {
              "1": "all",
              "2": "all",
              "3": "all",
              "4": "all"
            }
          }
        }

It should be sending a graph that looks like this, if it knows that all tables have unrestricted access:

        "data": {
          "schemas": "all"
        }

This was referenced Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Administration/Permissions Collection or Data permissions Priority:P2 Average run of the mill bug .Reproduced Issues reproduced in test (usually Cypress) Type:Bug Product defects
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants