Problem/Motivation

Lesson and curriculum authors need to be able to both invite collaboration and maintain creative control of their own work.

Proposed resolution

Enable authors to manage lessons and curriculum like project maintainers on drupal.org. Authors should be able to invite other maintainers to edit their lessons and curriculums, or optionally enable anyone to edit.

Remaining tasks

  • Confirm Project module is the module that adds maintainer functionality to project nodes on d.o.
  • If Project module is the module that adds maintainer functionality to project nodes,
    Use relevant node access and maintainer functionality to create a D7 Maintainer module.
    If not, figure out where d.o projects get this functionality, and figure out how we can repurpose it.
  • Implement an update hook in learn_glue to maintainer-enable lesson nodes
  • Enable Maintainer module by default with Learn Drupal distro in learn.info
  • Maintainer-enable lessons by default with Learn Drupal distro (in either learn.install or with Strongarm depending on how Maintainer module gets implemented)

User interface changes

Add maintainer tab to lesson and curriculum nodes modeled after d.o project maintainers, which looks like this:
https://skitch.com/bryan.hirsch/8c1w1/learn-drupal.org

API changes

None

Comments

jeffschuler’s picture

Project is indeed the module that provides the Maintainers functionality: in project.module and includes/project_maintainers.inc.

jeffschuler’s picture

Project: Learn » Drupal Ladder
Issue summary: View changes

Updated issue summary.

jeffschuler’s picture

Project: Drupal Ladder » Learn

What about using the Node access user reference module instead?

jeffschuler’s picture

Note 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.

jeffschuler’s picture

nodeaccess_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.

bryanhirsch’s picture

jeffschuler, 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.

jeffschuler’s picture

Project: Learn » Lessons
Version: 7.x-1.0-alpha3 » 7.x-1.0-alpha1
Status: Active » Needs review
StatusFileSize
new8.06 KB

Moving 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.

bryanhirsch’s picture

@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.

jeffschuler’s picture

1. I applied the patch in comment #8 and installed user_reference module.

I 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.

jeffschuler’s picture

I've made a patch to add proper Features support to the Node access user reference module: #1506552-11: Features support.
Reviews appreciated!

BrockBoland’s picture

Project: Lessons » Drupal Ladder
Version: 7.x-1.0-alpha1 »

This patch works, if the -dev version of nodeaccess_userreference is in use. Currently, the drupal-org.make in 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.

bryanhirsch’s picture

Version: » 7.x-1.x-dev

@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?

bryanhirsch’s picture

@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?

bryanhirsch’s picture

Update: 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.

bryanhirsch’s picture

I 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

bryanhirsch’s picture

Found 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:

338             nodeaccess_userreference_add_grant(
339               $grants,
340               'nodeaccess_userreference_author',
341               $node->uid,
342               $data['priority'],
343               $data['author']
344             );

(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.

bryanhirsch’s picture

Status: Needs review » Closed (fixed)

Committing Jeff's patch:
aaf284e61805af6cf9fc3e357f3cd4f5838515e1

bryanhirsch’s picture

Issue summary: View changes

Verified Project module contains functionality in question.