-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement createAccess for File entities #5479
Comments
Need to also consider 'bypass file access', the check is still incomplete. |
Done. |
Code looks good to me. I tested by invoking the method directly, and also through entity_access, and it works for me. 👍🏽 Incidentally, at the moment, this method is only used by entity_access. The file module, unlike other entity modules in core (node, comment and taxonomy), never invokes this method to check for create permission. Instead, this check is performed in file_file_access() by directly calling user_access. Perhaps this should be changed in a separate issue, to mirror the way it's done by those modules, and thus avoid checking for create access in two separate places? Before marking this as RTBC perhaps it'd be good to get some feedback about the above. |
pinging @backdrop/core-committers ^^ |
Yes, there seem to be some inconsistencies, which deserve a closer look. Unlike other access checks (view, update, delete - which are sometimes more fine-granular), it should (in theory) be possible to use createAccess consistently across entities. But I'd suggest to do that in a follow-up - the hook system might require some extra considerations. |
Closing in favor of #5480 |
All core entities except File implement a createAccess() override. As the default return value of Entity::access is TRUE, this leads to the problem that the value for File is always TRUE - ignoring "create files" permission.
Our assumption is currently, that not creating that override when adding entity_access in #3011 was an oversight.
I'm not sure if this is a bug or a feature request. Feedback is welcome.
Also related: #4975 - TRUE is a dangerous default value, anyway.
The text was updated successfully, but these errors were encountered: