Posted by ezra-g on February 18, 2013 at 8:43pm
3 followers
| Project: | Message |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Currently running entity_access() on a message entity (eg, as in #1918666]) will call message_access(), which simply returns the value of
<?php
user_access('create messages', $account);
?>In some cases, a module or modules may want to introduce a more complex set of access checking criteria. Currently, this can only be accomplished by implementing hook_entity_info_alter() and changing the 'access callback' value. One drawback of that approach is that only a single module or callback can be used within one installation of Drupal.
In Commons, we want the Commons Activity streams module to be enforce access criteria on all messages that it defines, and prevent users from seeing or receiving messages that reference nodes that the viewer/recipient cannot access.
Comments
#1
Patch attached defines hook_message_access_alter() and provides an example of how we're implementing this in Commons.
#2
I believe this is the correct solution. Regarding the draw back, same thing can be said about hook_menu()'s access callback. I'm setting to won't fix, but please re-open if you think otherwise.
#3
Thanks. For your consideration :
From my perspective, message access is different from a page access callback because it's more likely to have multiple different modules interacting with it depending on the situation.
For example, Commons wants to be able to restrict access for the Commons activity stream messages that contain certain entity reference fields, but have no effect on other message entities, such as the messages a user might add to her site unrelated to Commons.
This differs from a menu callback where it typically makes sense to have a single function responsible for a single path in all all cases.
#4
You could add to the above example with a scenario where one site has Commons controlling access to its own Message entities, and another contrib or custom module listening and controlling access to only its own set of entities.
#5
If anything I think we should follow the pattern of
hook_node_access()were you returnNODE_ACCESS_IGONRE/ DENY.However I'd be happy if you could profile it, as it might add a lot of overhead - better to know exactly how much.