DOC HistoryViewer: explain "magic names"
GraphQL scaffolding uses names consisting of the first part of the namespace and the classname, but to inject it to the HistoryViewer field you need to use the database table name.
Co-authored-by: Steve Boyd <emteknetnz@gmail.com>
We decided during implementation not to check permissions explicitly on cascading objects due to performance concerns.
For example, when publishing a page with embedded images, publish permissions on the image are implied - even if Image->canPublish() would return false for this author.
See https://github.com/silverstripe-security/security-issues/issues/57
This is a suggestion to update the docs to use the actual type names used in code. All the examples use the non-DB type names (ie: 'Wheels' => 'Int') but the bulleted list suggests it should be 'Wheels' => 'DBInt'. This is a bit confusing for new SS developers. Could we change this?
* Add missing rollback operation in scaffolding example
* Update block_id references to id to allow query to read query to run successfully in conjunction with HistoryViewerField
* BUGFIX many many through not sorting by join table
* #8534 added docs to support many many sorting fix
* #8534 added test cases for many_many default sorting
* BUGFIX many many through not sorting by join table
* #8534 added docs to support many many sorting fix
* #8534 added test cases for many_many default sorting
The ` $has_one` can be used both for `1-to-1` and `many-to-1` relations, depending on how is configured the inverse mapping on the related class. The documentation seems to suggest that `$has_one` implies a `1-to-1` relation, but then it gives an example of a `many-to-1` relationship. Since we are focusing on `$has_one` I would also put the `Player` class before the `Team` class.
- Stronger wording around "use composer"
- Consistent domain and email address naming
- Removed example for publishing non-composer modules (those shouldn't be encouraged)
- Removed instructions for installing modules from archives
[ci skip]
Sorry, first pull request. I added the Image and File use statements as requested. And surrounded the has_many example with the class name so it makes more sense.
Adding a relationship to core classes brings some extra syntax issues. I think it would be usefull to not that core classes are realted through Image::class and that a has-one-relationship needed on a core class when relating them thru has_many, can be set up through yml.
