Why does it take a long time to remove access of a user from Shared Folder?

Knowledge Drop

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.                

Version history
Last update:
‎06-14-2021 06:17 PM
Updated by: