c1cda2b113
* DOCS: Add new graphql 4 docs * Reorganise docs * Docs done * Basic graphql index page * TOC for getting started * show folders on graphql index page * Add middleware note * Docs update * Update docs to reflect flushless schema * Docs updates * Docs for getByLink * Query caching docs * Docs on nested operations * update docs for new graphql dev admin * Docs for configurable operations * Replace readSiteTrees with readPages * Schema defaults docs * Docs for inherited plugins * Docs for customising * * Docs for field whitelisting * Change whitelist word * New docs on modelConfig * Document dev/build extension * Document default/global plugins * Document new input type fields config * Apply suggestions from code review Co-authored-by: Andre Kiste <bergice@users.noreply.github.com> * Note about when procedural schema gets built * Fix link * Apply suggestions from code review Co-authored-by: Andre Kiste <bergice@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Andre Kiste <bergice@users.noreply.github.com> * DOCS Note about plugins in custom queries * DOCS Note about filter and custom resolvers * DOCS Note about canview paging * DOCS Updated guidance on _extend See https://github.com/silverstripe/silverstripe-graphql/issues/296 * Apply suggestions from code review Co-authored-by: Andre Kiste <bergice@users.noreply.github.com> * DOCS Pre-release warning Co-authored-by: Ingo Schommer <ingo@silverstripe.com> Co-authored-by: Andre Kiste <bergice@users.noreply.github.com> Co-authored-by: Ingo Schommer <me@chillu.com>
2.6 KiB
| title | summary |
|---|---|
| DataObject operation permissions | A look at how permissions work for DataObject queries and mutations |
Working with DataObjects
[CHILDREN asList]
[alert] You are viewing docs for a pre-release version of silverstripe/graphql (4.x). Help us improve it by joining #graphql on the Community Slack, and report any issues at github.com/silverstripe/silverstripe-graphql. Docs for the current stable version (3.x) can be found here [/alert]
DataObject operation permissions
Any of the operations that come pre-configured for DataObjects are secured by the appropriate permissions by default. Please see Model-Level Permissions for more information.
Mutation permssions
[info]
When mutations fail due to permission checks, they throw a PermissionsException.
[/info]
For create, if a singleton instance of the record being created doesn't pass a canCreate($member) check,
the mutation will throw.
For update, if the record matching the given ID doesn't pass a canEdit($member) check, the mutation will
throw.
For delete, if any of the given IDs don't pass a canDelete($member) check, the mutation will throw.
Query permissions
Query permissions are a bit more complicated, because they can either be in list form, (paginated or not), or a single item. Rather than throw, these permission checks work as filters.
[notice]
It is critical that you have a canView() method defined on your dataobjects. Without this, only admins are
assumed to have permission to view a record.
[/notice]
For read and readOne a plugin called canView will filter the result set by the canView($memeber) check.
[notice]
When paginated items fail a canView() check, the pageInfo field is not affected.
Limits and pages are determined through database queries,
it would be too inefficient to perform in-memory checks on large data sets.
This can result in pages
showing a smaller number of items than what the page should contain, but keeps the pagination calls consistent
for limit and offset parameters.
[/notice]
Disabling query permissions
Though not recommended, you can disable query permissions by setting their plugins to false.
app/_graphql/models.yml
Page:
operations:
read:
plugins:
canView: false
readOne:
plugins:
canView: false
Further reading
[CHILDREN]