Thank you @presleyp . I dropped this in the RBAC epic for now.
CC: @Emyrk FYI

Thanks.
@presleyp and I talked about ways to handle this.

One solution

The backend could support an endpoint that allows users to query if they can do some action. This does not leak any information. The admin menu has: Users, Audit log, Metrics, .... The query could support a list of "resource" and "actions" for the UI to make informed decisions on.

Eg:
Should we show the "Settings" dropdown in "Admin"?
The query to the backend can have {"resource_type":"admin_settings", action:"read"}, which will return true for admins, but not for members. This would work to indicate which options to show:

{ // Total WIP structure. Just a very basic example
  "show_settings": {"resource_type":"admin_settings", action:"read"},
  "audit_logs": {"resource_type":"audit_log", action:"read"}
}

Hey team! Please add your planning poker estimate with ZenHub @code-asher @presleyp @vapurrmaid

Estimated at 13 because we are blocked on the design of permissions.

Can fill in more context later/synchronously. Will need to take a look at other tickets and match up the dependencies.

Once we understand the design of perms and the approach the FE will take, we will need to implement that.

Once we're here, this will become a 2, max 3, pointer.

But I don't want this to be lumped in with the broad architecture of permissions.

It's a little strange to me for this to be a 13 now but a 2 later. Shouldn't permissions design be separate?

@Emyrk @vapurrmaid @presleyp do we need a synchronous conversation to sort this one out?

@tjcran yes

About this one, what pages should we verify? I can only see for now the user's page being affected. Am I missing something?