Currently, when a module or core checks for an entity operation that Group does not know about, one of two things happen:
- Is it targeted at a group entity? Return Neutral
- Is it targeted at a grouped entity? Return Forbidden
I still believe that if Group knows how to handle the operation, we should return Forbidden if the group permission is missing, but if there is no module telling Group how to deal with the operation, we should just return Neutral and allow the module (or core) that exposes the operation to handle it.
Assume there is a module that allows you to favorite a node using the "favorite" operation. If the node was grouped by gnode, in 8.x-1.x, you would not be allowed to favorite it even though there's no way to make Group allow it through any of the permissions. In 2.0.x it will be allowed unless there is a bridge module telling Group what group permission the favorite operation maps to. At that point, you would need to have said group permission.
This will need a change record for sure.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | group-3257948-5.patch | 26.25 KB | kristiaanvandeneynde |
Comments
Comment #2
kristiaanvandeneyndeThis still needs tests and might break a few existing ones, but the new supportsOperation method should give developers enough control to alter the default behavior added in this patch.
Comment #4
kristiaanvandeneyndeThis fixes the existing tests. We need a unit test for the new method and a kernel test to prove that forbidden is returned when the operation is supported and neutral when it isn't.
Comment #5
kristiaanvandeneyndeAdding unit tests, now to add kernel tests and a change record and we're done.
Comment #7
kristiaanvandeneyndeAdded some kernel tests, committed it and will write up the CR next.