Hello,
We are using content_profile to build a set of different profiles for our users: we are using two content types, one for each role, and they share some of the cck_fields.
We want the profiles to be viewable only for the owner of the profile, therefore we were using content_access to disallow the rest of users to access others' content profile nodes as is recommended in the documentation. The problem is we are using some of those fields afterwards in some of the views, and they are not displayed for the rest of the users. We have been testing some other access control modules: simple_access, node_privacy_by_role, etc., but we have not been able to achieve this functionality,
We were wondering which are the best practices for this case:
- Content_profile to construct the profiles.
- Users should only be able to access their own profile.
- We use some of those fields afterwards in views, and these views are displayed in a public way (although the profiles should remain private). In one way we need views to "overcome" those viewing permissions set by content_access module (I do not know if this is "clean" from an architectural point of view).
I have seen there are some similar issues in the queue (i.e.: http://drupal.org/node/1222516), but I decided to create a new one since this is more focus on the relationship with this module and views.
Thanks a lot in advance for your help,
David
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | wikisaber_deny_content_profile_access.tar_.gz | 994 bytes | drozas |
| #1 | wikisaber_deny_content_profile_access.tar_.gz | 857 bytes | drozas |
Comments
Comment #1
drozasFind attached a very simple custom module (very project dependent - I will try to create a more generic one and upload it to the repositoryin the future - see readme), to return a 403 response in case users that do not have a custom bypass permission try to view the node. I thought that the code might be useful for someone else.
David
Comment #2
drozasAdded a new version of the code that checks if the node belongs to that user (to avoid a 403 response in /user, since it is loading the content profile node).