View the original community article here
Last tested: Feb 26, 2021
To summarize: After the DELETE /api/internal/core/3.1/content_metadata_access/331, {}
, Looker runs several queries as below (note: not all queries are listed here -- I am pasting some examples to illustrate the process):
Step 1: Confirm the permission of the user performing the action:
SELECT * FROM "USER" WHERE ("ID" = 70) LIMIT 1
SELECT * FROM "SESSION" WHERE ("TOKEN" = '[FILTERED]') LIMIT 1
Step 2: Get the ID of Looks, Dashboards, Spaces, etc inside the Shared Folder:
SELECT * FROM "LOOK" WHERE ("LOOK"."ID" IN (1, 11))
SELECT * FROM "DASHBOARD" WHERE ("DASHBOARD"."ID" IN (1, 2, 3, 41, 52, 65, 91, 93, 97, 105, 109, 110))
SELECT * FROM "CONTENT_METADATA" WHERE ("CONTENT_METADATA"."PARENT_ID" = 37)
Step 3: Looker inserts the action into the "Event" and commit "transaction" to remove access
INSERT INTO "EVENT" ("NAME", "CATEGORY", "CREATED_AT", "USER_ID", "SUDO_USER_ID", "IS_LOOKER_EMPLOYEE", "IS_ADMIN", "IS_API_CALL") VALUES ('delete_content_metadata_access', 'content_metadata', TIMESTAMP '2021-02-27
delete_content_metadata_access by user 70:, content_metadata_id='1', group_id='', user_id='26', permission_type='edit', content_type='space'
Request complete: 204
With this being said, if an instance has many users, and folders (spaces), dashboards and looks inside sub folders of the "Shared Folder", it would take a substantial amount of time to update the process.
This content is subject to limited support.