Posted by kenorb on October 20, 2008 at 2:35pm
| Project: | View own |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Here is the patch to enable additional permission which can be use to grant permission to a user (such as view, edit or delete) which is referenced via userreference or nodereference fields.
| Attachment | Size |
|---|---|
| view_own.module.patch | 2.82 KB |
Comments
#1
You can try as well this module:
http://drupal.org/project/nodeaccess_userreference
#2
#3
Is this will be implemented?
#4
Commited, need testing.
I'm not sure about the permission names if they are correct.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.
#6
I tested the dev release but got error's like duplicate keys. I think you better remove this 'feature' and let the module http://drupal.org/project/nodeaccess_userreference handle it.
It works great this combi! Thanks for your part.
#7
Thanks, but this module still doesn't support nodereferences #461360: Node Access based on user reference from related node ;(
#8
http://drupal.org/project/nodeaccess_autoreference
#9
#10
#11
Automatically closed -- issue fixed for 2 weeks with no activity.
#12
I'm not sure if I should open a new issue for this, but I was finding that this patch sometimes opens unintended access to nodes for some users.
It looks like under the following conditions...
- groups G1, G2, G3, ... have the "edit ____ via ____" permission
- node A has a userreference to user B
- user B is not a member of any groups G*
...user B gets access to node A even though user B shouldn't.
The reason seems to be that the section checking the references is within the loop sweeping all roles.
I'm attaching a patch that appears to fix this for userreferences, but:
1. It needs more testing (I only tested cases where the user SHOULDN'T have access).
2. I had to comment out the nodereference part, because after reading and rereading the code and descriptions of its functionality, because
a) I still don't understand what the intended functionality is (i.e. who gets access to what under what conditions).
b) Also, it seems that that functionality has been split off into another (compatible) module anyway.
kenorb, comments and help on this?
3. I'm not sure if a similar bug exists with ____ own ____ content (since it is in the part of the code that loops through all roles). So far, testing on my end seems okay.
Thanks,
Al
#13