Skip to content

Use previous state of CampCollaboration for ACL check in CampRoleVoter #8125

@BacLuc

Description

@BacLuc

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions