Apply workaround for update permission check for rules with relational fields #19728
Conversation
🦋 Changeset detectedLatest commit: c4b79ba The changes in this PR will be included in the next version bump. This PR includes changesets to release 15 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
paescuj
requested review from
a team,
rijkvanzanten,
br41nslug and
DanielBiegler
and removed request for
a team
There was a problem hiding this comment.
Although this is a workaround, it works and still technically somewhat reverts to the old isAllowed behavior. Although isAllowed used to work for cases such as #19327, it actually did not work properly hence the incorrect impression of it working.
For additional context, the isAllowed util before #18871 was technically not checking the perms correctly, hence #16731 was an issue where a uneditable field was shown as editable.
However the issue now is when we do check perms recursively in the App, the current value that it is checking against is not as detailed as what the API uses (as API fetches nested values). If we were to go down the route of fetching the nested values retroactively on the App side, we may be re-doing the API's logic over in the App. 🤔
A better fix would potentially be that permissions are checked solely in the API rather than the App, which will ideally resolve #11059 as well.
Great summary 😇👍 |
…l fields (directus#19728) * Apply workaround for update permission check for rules with relational fields * Add basic update tests for isAllowed * Enhance parseFilter tests * Add changeset
Addresses #19327
Temporary workaround, currently necessary for permission rules containing relational fields because those relational values aren't available in the
isAllowedupdate check and it would therefore always fail.For now, the check is instead always considered successful in such a case, ensuring items can be update again.
Though, this means items might be presented to the user as "updatable" even if they aren't, but the API will correctly refuse the update in that case and the
You don't have permission to access thismessage will be shown.A complete solution will be provided at a later date.