/api/v1/db_info
POST /db_info/create
POST /db_info/createRetrieve information about if objects can be created in a specific object type and pool configuration. Tags can also be provided to perform the check.
- With no further parameters, object types are returned where the user can create new objects:
for a pooled objecttype this checks each pool for the
createright; a non-pool objecttype is listed if it grants thecreateright directly. - With
objecttypeset, a list ofpool_idsis returned alongside the object type. - With
tag_idsunsent the server uses the default tag set for the objecttype/pool combination to check the rights. - With
tag_idsprovided, these ids are used to check the rights. - With
tag_idsset tonull, the rights are checked without tag filters.
Access token in the Authorization header:
Authorization: Bearer <token>.
The access token in form of Bearer <token>. You can also use authorization
which does the same. authorization is looked at first.
The access token in form of Bearer <token>.
The object type to check the create permissions for. If omitted, the check will include all object types.
The ID of the pool to check the permissions for.
List of tag IDs which are assumed for the new object. If
omitted, the check will include the default tags. If set to
null, the tags check will be omitted. This can be useful if
only a certain combination (which is not the default
combination) of tags enables permissions for the user. An id
that matches no tag returns code TagNotFound; an id that
exists but is not enabled for the objecttype/pool returns code
TagNotEnabled. These two codes are raised only by
db_info/create.
An object describing the possibilites to create an object for the user.
The permission check could not be performed. When present, the code
field of the response identifies the specific reason; not every 400
carries a stable code (input-validation failures are returned as
generic messages).
No authenticated user. The request must carry a valid access token.
Differs from easydb 5: a missing/invalid session is reported as 401
(UnauthorizedError); easydb 5 documents the unauthenticated case as a
400.
POST /db_info/update
POST /db_info/updateRetrieve information about how objects can be updated using a new pool or tags.
- An
objecttypeandobject_idsmust be provided. If either is missing, the request fails with a generic400. - If a pool change is planned, the
pool_idas the new pool ID can be sent. All permission compilations are done with the new pool ID, except for theunlinkpermission which is checked against the current pool ID of the object(s). - Masks, tags and pools are listed only if they apply to all object(s).
This is a read-only permission probe. Passing pool_id or tag_ids
computes the rights as if the object(s) had been moved or retagged, but
no object is actually modified.
Differs from easydb 5: _available_masks and _available_tags are
populated only when the session holds the read right on every probed
object; easydb 5 documents these two lists as "only provided if 'write'
is in _generated_rights".
Access token in the Authorization header:
Authorization: Bearer <token>.
The access token in form of Bearer <token>. You can also use authorization
which does the same. authorization is looked at first.
The access token in form of Bearer <token>.
The object type to check the update permissions for.
The object IDs to check permissions for.
The ID of the pool to check the permissions for. This assumes that the object(s) will be moved to that pool.
List of tag IDs which are assumed for the updated object. If
omitted, the check will use the current tags of the object(s).
Setting null is the same as setting []. This assumes that
the update will remove all tags from the object(s).
A list of masks, pool IDs, tags and _generated_rights compiled for all objects together. The lists contain only items which are available for all objects.
List of pool IDs the object(s) can be in. The current pool of
the object(s) is always included (when shared by all object(s)).
A different destination pool is listed only if the user holds
the unlink right in the current pool and the link right in
that destination pool. system.root sees all pools. Only
populated when the requesting session holds read on every
object.
The permission check could not be performed. When present, the code
field of the response identifies the specific reason; not every 400
carries a stable code (input-validation failures are returned as
generic messages).
No authenticated user. The request must carry a valid access token.
Differs from easydb 5: a missing/invalid session is reported as 401
(UnauthorizedError); easydb 5 documents the unauthenticated case as a
400.
Last updated