There is currently no straightforward way for an API client to determine which permissions the authenticated user has for a record (e.g. preview, edit, or manage). This is needed, for example, to decide which actions should be displayed to the user in a UI.
Current Workaround
The best way we have found to determine the permissions is:
-
Check if the record details: If parent.access.grants is present (including an empty list), we can assume "manage" permissions because the field will be hidden if the authenticated user does not have those permissions.
-
Otherwise, check if the user has "edit" permissions using a query
-
GET /api/user/records?q=id:<record-id> AND parent.access.grant_tokens:<token>&page=1&size=1
-
The grant token is the dot-separated Base64 encoding of user, the cached user ID, and edit (including normal Base64 padding): <base64(subject_type).base64(subject_id).base64(permission)>
-
Assume edit permissions when the query has a hit and preview otherwise. (If the record is potentially not a user record, we can check the other permissions in the same way.)
This is quite convoluted and relies on implementation details that API clients ideally should not need to know about. Relying on grant_tokens being indexed for this purpose also does not seem like a good long-term API contract.
Proposed Solution
It would be useful if the record representation explicitly exposed the effective permissions of the authenticated identity, for example:
{
"permissions": "manage"
}
For this field to actually be useful, it should not be hidden if the authenticated user has lower permissions than “manage”, as it is currently the case for parent.access.grants.
There is currently no straightforward way for an API client to determine which permissions the authenticated user has for a record (e.g.
preview,edit, ormanage). This is needed, for example, to decide which actions should be displayed to the user in a UI.Current Workaround
The best way we have found to determine the permissions is:
Check if the record details: If
parent.access.grantsis present (including an empty list), we can assume "manage" permissions because the field will be hidden if the authenticated user does not have those permissions.Otherwise, check if the user has "edit" permissions using a query
GET /api/user/records?q=id:<record-id> AND parent.access.grant_tokens:<token>&page=1&size=1The grant token is the dot-separated Base64 encoding of
user, the cached user ID, andedit(including normal Base64 padding):<base64(subject_type).base64(subject_id).base64(permission)>Assume
editpermissions when the query has a hit andpreviewotherwise. (If the record is potentially not a user record, we can check the other permissions in the same way.)This is quite convoluted and relies on implementation details that API clients ideally should not need to know about. Relying on
grant_tokensbeing indexed for this purpose also does not seem like a good long-term API contract.Proposed Solution
It would be useful if the record representation explicitly exposed the effective permissions of the authenticated identity, for example:
{ "permissions": "manage" }For this field to actually be useful, it should not be hidden if the authenticated user has lower permissions than “manage”, as it is currently the case for
parent.access.grants.