Fix category field to correctly manage edit.state permissions in combina... #722
Conversation
…ination with other permissions.
|
Unit testing complete. There were 0 failures and 0 errors from 1971 tests and 11146 assertions. |
|
Build triggered by changes to the head. Unit testing complete. There were 0 failures and 0 errors from 1971 tests and 11146 assertions. |
|
I actually want to add that I don't know if this belongs in the platform except to the extent that it already integrates permissions. I'm not sure that category by itself shouldn't just be a list of categories and then somehow the user can apply permission rules to it. But it is what it is right now, it's paying attention to some permissions but not others and that is making it broken for the ways that it is used. Part of me thinks that the cms should just have its own field extended from the base category field that works in ways that make sense in context. |
| // unless the item is already in that category. | ||
| // Unset the option if the user isn't authorised for it. In this field assets are always categories. | ||
| if ($user->authorise('core.create', $extension . '.category.' . $option->value) != true) | ||
| foreach ($options as $i => $option) { |
There was a problem hiding this comment.
The opening curly brace should be on a new line.
Fix category field to correctly manage edit.state permissions in combination with other permissions.
Currently when a user has edit for an item but not edit.state the category field returns a blank list of options. There are also situations where the user may have create in other categories but not edit.state in the category of the current item. In that case (contrary to current behavior) the option to change category should not be given but only the current category should be shown.