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.
* API Support many_many through polymorphic relations (from side only)
Fixes#7911Fixes#3136
* Add extra docs and allow optional arguments
* ENHANCEMENT Enable quiet to be turned off
* BUG Fix issue with manymanythroughlist duplication
