Closed (fixed)
Project:
Drupal Ladder
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
23 Mar 2012 at 08:28 UTC
Updated:
8 Aug 2012 at 11:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
jeffschulerProject is indeed the module that provides the Maintainers functionality: in project.module and includes/project_maintainers.inc.
Comment #1.0
jeffschulerUpdated issue summary.
Comment #2
jeffschulerWhat about using the Node access user reference module instead?
Comment #3
jeffschulerNote that the 7.x-3.x-dev version of nodeaccess_userreference supports the entityreference module, while 7.x-3.6 still requires the references module.
Comment #4
jeffschulernodeaccess_userreference works decently as a solution here.
I added an entity [user] reference field called Lesson editors to the Lesson content type and configured to provide Update access to referenced users. The author of a lesson can then reference users as editors of that lesson.
Looks like, as-is, those editors can themselves edit that Lesson editors field -- so they can add/remove editors, too. We might want to control access to that field manually (grant only to author & admins) or with Field Permissions.
Comment #5
bryanhirsch commentedjeffschuler, nodeaccess_userreference looks great plan to me. My knee jerk reaction is that Field Permissions is more overhead than we need right now. Let's get the Lesson Maintainers functionality hammered out and working the way we want it. We can always add Field Permissions if lesson maintainers need this additional level of control.
Comment #6
jeffschulerMoving this to the Lessons queue.
This is a feature for Lessons that adds a user reference field to the Lessons and Curriculum content types: Lesson maintainers and Curriculum maintainers.
It uses Node access user reference to give the users referred-to by these fields update access to the node that's referring.
nodeaccess_userreference stores its configuration in a single variable, so in addition to adding those fields, this feature strongarms that variable.
I will open a new issue and patch the Learn distro to include the nodeaccess_userreference module if-and-when this gets through.
Comment #7
bryanhirsch commented@jeffschuler, two questions:
1. I applied the patch in comment #8 and installed user_reference module. But I can't get this to work. I'm using Devel Generate to create users. Then I add user X as a maintainer of a lesson created by user Y. But when I sign in as user X, I can't edit the lesson authored by user Y.
2. I wonder if there might be conflicts between references and entityreference. Have you looked at this? Since it looks like References is likely to be deprecated in favor of Entity Reference, I wonder if we need to update nodeaccess_userreference to use entityreference rather than user_reference.
Comment #8
jeffschulerI assume you mean in #6 and nodeaccess_userreference?
Sorry: I should've noted that you'll currently need the 7.x-3.x-dev version of nodeaccess_userreference; a Feb 19th, 2012 commit adds entityreference support.
You shouldn't need the references module at all.
It's also possible that strongarming the variable that stores nodeaccess_userreference data is not enough to featurize its functionality, (though IIRC it worked for me.) I have a ticket open for Features support for nodeaccess_userreference.
Comment #9
jeffschulerI've made a patch to add proper Features support to the Node access user reference module: #1506552-11: Features support.
Reviews appreciated!
Comment #10
BrockBoland commentedThis patch works, if the -dev version of nodeaccess_userreference is in use. Currently, the
drupal-org.makein the drupalladder project uses 3.6. Once the patch on that issue is in place (#1671410: Use -dev version of nodeaccess_userreference) this patch can be committed.Comment #11
bryanhirsch commented@BrockBoland @jeffschuler, I applied Jeff's patch. I enable lessons_maintainers module. Jeff's settings are there. But the access control part doesn't seem to work for me. I've tried this with 7.x-3.8, 7.x-3.x-dev and a checkout of 2b442276e101325e6b123cbe8c18a7dd83a39284. It looks to me like anonymous users can always see an edit tab, whether they have permission to edit the node or not. It also looks to me like co-maintainers can't actually edit any fields.
Are you two seeing something different?
Comment #12
bryanhirsch commented@BrockBoland @jeffschuler, I applied Jeff's patch. I enable lessons_maintainers module. Jeff's settings are there. But the access control part doesn't seem to work for me. I've tried this with 7.x-3.8, 7.x-3.x-dev and a checkout of 2b442276e101325e6b123cbe8c18a7dd83a39284. It looks to me like anonymous users can always see an edit tab, whether they have permission to edit the node or not. It also looks to me like co-maintainers can't actually edit any fields.
Are you two seeing something different?
Comment #13
bryanhirsch commentedUpdate: I've got nodeaccess_useraccess working correctly on a new custom content type. I'm still not sure where things are falling apart with lessons_maintainers though.
Comment #14
bryanhirsch commentedI think I found the problem, I'm just not sure what's causing it yet. gid is defaulting to 0 for lessons. We want gid = 1 like this:
https://skitch.com/bryan.hirsch/ek5pm/terminal-mysql-163x28
Comment #15
bryanhirsch commentedFound the problem:
1. Content imported on install sets author to uid 0 (anonymous).
2. Nodeaccess_userference implements hook_node_access_records() and saves gid = 0 here:
(nodeaccess_userreference.module)
3. As a result, anonymous users are being granted permission to view, update, delete content that ships with the distro by default.
https://skitch.com/bryan.hirsch/emdra/getting-started-create-an-issue-re...
I opened an issue to track this as a bug here: http://drupal.org/node/1716460.
Comment #16
bryanhirsch commentedCommitting Jeff's patch:
aaf284e61805af6cf9fc3e357f3cd4f5838515e1
Comment #16.0
bryanhirsch commentedVerified Project module contains functionality in question.