Working with DataObjects

DataObject query plugins
Learn about some of the useful goodies that come pre-packaged with DataObject queries
DataObject operation permissions
A look at how permissions work for DataObject queries and mutations
Versioned content
A guide on how DataObjects with the Versioned extension behave in GraphQL schemas
DataObject inheritance
Learn how inheritance is handled in DataObject types
Property mapping and dot syntax
Learn how to customise field names, use dot syntax, and use aggregate functions
Nested type definitions
Define dependent types inline with a parent type
The DataObject model type
An overview of how the DataObject model can influence the creation of types, queries, and mutations
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

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

When mutations fail due to permission checks, they throw a PermissionsException.

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.

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.

For read and readOne a plugin called canView will filter the result set by the canView($memeber) check.

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.

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

DataObject query plugins
Learn about some of the useful goodies that come pre-packaged with DataObject queries
DataObject operation permissions
A look at how permissions work for DataObject queries and mutations
Versioned content
A guide on how DataObjects with the Versioned extension behave in GraphQL schemas
DataObject inheritance
Learn how inheritance is handled in DataObject types
Property mapping and dot syntax
Learn how to customise field names, use dot syntax, and use aggregate functions
Nested type definitions
Define dependent types inline with a parent type
The DataObject model type
An overview of how the DataObject model can influence the creation of types, queries, and mutations