-
Notifications
You must be signed in to change notification settings - Fork 62
Description
It's okay for me to merge now, to fix this one case. However I'd like to have a more general fix in the voter some time. The voter could load the original data of $subject before the change from the db and perform the permission check on that old version of the object. Or, to gain access to the request context, like AssertAllowTransitionsValidator, the Voter could get a RequestStack object and then get the old version of the subject via $this->requestStack->getCurrentRequest()->attributes->get('previous_data') (but maybe make sure the subject is really equivalent to the entity being mutated, by checking iri equality)
Originally posted by @carlobeltrame in #7740 (review)
I tried this in
and failed, in the end because the voter is not called in case it's about the own CampCollaboration.
https://github.com/ecamp/ecamp3/blob/e84dedfaea76fc2544691fbd864b961c1298b234/api/src/Entity/CampCollaboration.php#L40,L46
We could either move all the condition parts into the Voter, which would make the voter more complex.
Or a different set of fields can be updated depending on your role and if you are editing your own collaboration or not.
We could either move "leaveCamp" to a separate RCP Operation, or use dynamic denormalization contexts, or use a validator which takes over the job which is currently in the processor.
All this doen't make it simpler and very much better, so we leave it for now.