Hello, on my sandbox site I have the 3 default roles: Admin, Auth. user and Anon.

I've played with visibility of nodes with various combinations and it all seems to run smoothly.

Now, on a node, I grant via your module EDIT rights to Authenticated User #10 (and others subsequently). That does not seem to work, those users can see neither an "Edit" tab nor can they visit node/%/edit.

CommentFileSizeAuthor
#11 nuarog_access_alter.zip1.59 KBBPm
#8 NAUROG-access_alter.zip1.52 KBRenee S
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

magtak’s picture

magtak CreditAttribution: magtak commented

Sorry, when I say "edit" rights I mean the "Update" checkbox. I suppose that's what it does, right? :)

magtak’s picture

magtak CreditAttribution: magtak commented

And the Devel Node Access thingy produces this in a soothing green color:

node prio status realm gid view update delete explained
31 0 ok nodeaccess_userreference 13 1 1 0 Referenced user jt10 may view/update this node

so i can't see why it wouldn't work.

magtak’s picture

magtak CreditAttribution: magtak commented

Sorry for the update spam but I am figuring this out in batches:

Some more devel information says that organic groups' permissions somehow conflict with Node access user reference's.

Is there anyway to bypass this? In my current example, the user "jt10" is a member of the group, members of the group do not have editing rights, but I want to have that option via some sort of invite, and that would be where your module comes into place.

username create view update delete
Anonymous (not verified) NO: no reason YES: {node_access} NO: by og NO: by og
jt YES: bypass node access YES: bypass node access YES: bypass node access YES: bypass node access
jt10 NO: no reason YES: {node_access} NO: by og NO: by og
magtak’s picture

magtak CreditAttribution: magtak commented
Status: Active » Closed (fixed)

Nevermind, http://drupal.org/node/1171834#comment-6019078 answers it.

Renee S’s picture

Renee S CreditAttribution: Renee S commented

It answers it, sort of, but it still won't work. The modules seem to be incommensurable.

Scenario 1: OG_Access comes first.
- nodeaccess_userreference totally ignored, for update and delete as well as view

Scenario 2: NAUR comes first
- OG_Access view settings are ignored.
-- If you have the View All grant set, then you can't use OG's private content setting
-- If you don't have it set, you can't use OG's public content setting

magtak’s picture

magtak CreditAttribution: magtak commented

Indeed you are right Reinette, I ended up using OG in conjunction with my own custom module to satisfy my complicated content access needs.

Renee S’s picture

Renee S CreditAttribution: Renee S commented

Aaah, I was just experimenting with this myself last night, and came to the conclusion that a little custom module is needed to alter the priority weights of the node grants depending on whether the node is set to OG_CONTENT_ACCESS_PRIVATE. Would you be willing to share your work? :)

Renee S’s picture

Renee S CreditAttribution: Renee S commented
FileSize
NAUROG-access_alter.zip1.52 KB

Ok, based on @magtak's and @BPm's work, helper module attached for anybody who needs it -- mediates between OG and NUAR, giving OG's 'view access' precedence (so private stays private even with "Grant view all" set in NUAR) yet still allowing nuar's edit/delete access to work in OG context. Also gives NUAR user view access if they have edit/delete access. Needs testing...

Renee S’s picture

Renee S CreditAttribution: Renee S commented
Status: Closed (fixed) » Needs review

@danielb, I'm not actually sure if this is "fixed" because it's not a bug, exactly. Needs review? Eh, anyway... :)

magtak’s picture

magtak CreditAttribution: magtak commented

@Renee S nice to see that my code helped you out :) Sorry if it was too specific. It's tailored to my project's needs which as you saw from the code where a bit convoluted hehe

BPm’s picture

BPm CreditAttribution: BPm commented
FileSize
nuarog_access_alter.zip1.59 KB

Hello,
This is a new version of the hack.
This hack is way shorter (1 function) and allows multiple user referenced fields to reference the same user

bsandor’s picture

bsandor CreditAttribution: bsandor commented
Title: Granting "Edit" rights on node doesn't seem to work. » Granting "Update" rights on node doesn't seem to work.

I've tried both of these version and none of them work for me.

I use NAUR 3.9 & OG 7.2

Both of them keep the original behavior: "update" doesn't work for me.

Also I changed title from edit to update of current issue.

bsandor’s picture

bsandor CreditAttribution: bsandor commented
Title: Granting "Update" rights on node doesn't seem to work. » Granting "Update" rights on node doesn't seem to work (with using OG)

Wow: After many hours and luck my result is:
once you have OG Settings / 'Strict node access permissions' swithed off: NAUR works fine with update access,
once you have it on: it fails giving update access even dough in node_access table proper settings are.
Also none of #8 or #11 work for me (once that switch is on)

NOUR 3.9
OG 2.0

danielb’s picture

danielb CreditAttribution: danielb commented
Issue summary: View changes
Status: Needs review » Closed (won't fix)

There is no patch to review here, and I'm not convinced NAUR is doing something wrong.
It sounds like the above post has found a solution regarding user access. I'm not an OG user (in fact as I understand it many people use this module in lieu of OG) but this module is designed to work with other node access modules.
It sounds like OG and this module might be butting heads when OG is in some particular configuration, in which case that's beyond the scope of this project. Of course if you can show this module is doing something wrong (in code) we can take another look at that.