IBX-6592: Allowed Location to be a part of permission check for Object State assignment

[barw4]

Question	Answer
Tickets	IBX-6592
Bug fix?	yes
New feature?	no
BC breaks?	no
Tests pass?	yes
Doc needed?	no
License	GPL-2.0

Requires: ezsystems/ezplatform-kernel#391

Currently, Content Object State assignment is done utilizing ContentInfo, which in my opinion is wrong, as that leaves Subtree Limitation pretty much useless, and yet, this limitation is available for a choosing when we are dealing with the state/assign policy.

Therefore, ContentInfo was replaced with Location everywhere where it touches Object States assignment.

Checklist:

• Coding standards ($ composer fix-cs)
• Ready for Code Review

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
2.6% Duplication

[ViniTou]

that's a bc break, I guess we should create new route and deprecate that one.

[ViniTou]

Suggested change

	function () use ($objectStateGroup, $location) {
	function () use ($objectStateGroup, $location): array {

[ViniTou]

Suggested change

	function (ObjectState $objectState) use ($location) {
	function (ObjectState $objectState) use ($location): bool {

[Nattfarinn]

This is not correct approach. We can't make our permission layer to behave differently if used from UI and used as API.

[barw4]

This is not correct approach. We can't make our permission layer to behave differently if used from UI and used as API.

@Nattfarinn where exactly does it behave differently than what we have in the API?

[Nattfarinn]

@Nattfarinn where exactly does it behave differently than what we have in the API?

This additional argument is used only in ibexa/admin-ui. I know this was done to keep BC, but existing API calls that won't use Location will behave differently and would force everyone to update all their API calls (what about REST calls?) to use additional parameter to make it work the same. If we insist on keeping BC here (ping @alongosz), we should at least be able to do that without changes to API.

This could/should be solved in https://github.com/ezsystems/ezplatform-kernel/blob/1.3/eZ/Publish/Core/Limitation/SubtreeLimitationType.php by handling special case (maybe check $targets for ObjectState?) but this would need at least @alongosz decision/expertise/omniscience.

[webhdx]

We put more thought into this change and we can't change the API to facilitate Locations only to be used as a part of Permission check. I think the proper solution is to remove LocationSubtree limitation from state:assign policy and fix the documentation. It was never working correctly and I believe it was added by a mistake since Object State API doesn't work with Locations at all.