Nodequeue Companion Modules (Project Wiki)

Project Information

Drupal.org project pages:
[1] http://drupal.org/project/smartqueue_users
[2] http://drupal.org/project/smartqueue_og

Description

This proposal consists of two related modules, user_nodequeue and og_nodequeue, both of which are built using the Smartqueue API provided by the NodeQueue module. For detailed specifications, see the Project Proposal

The user_nodequeue module [1]

The user_nodequeue module would benefit end users and administrators of Drupal sites that call for nodequeues which correspond to individual users.
Provided with a nodequeue that displays on the user profile page, each user would have the opportunity to highlight content of her choosing. A user is more likely to use a nodequeue when one is provided for her, since some users may be unwilling, unable or simply uninterested in performing the steps necessary to create a nodequeue.
Currently, if a site administrator wishes to provide nodequeues to many of her users, she must manually create each nodequeue. On a site with hundreds or thousands of users, this can be a prohibitively time-consuming task. Additionally, displaying nodequeues on user profile pages calls for the writing of PHP code, a skill that many casual Drupal site administrators lack.
The user_nodequeue module would fulfill these use cases without requiring either the manual creation of nodequeues or PHP coding skills.
User_nodequeue could also be configured in such a way that individual users cannot manipulate their own nodequeues (see #5 in the Deliverables section). This allows for a list of selected content by a particular user that is maintained internally by website administrators/moderators. Such a configuration would enable various use cases, such as when administrators want to highlight offensive content by a particular user (as suggested by greggles).

User_nodequeue (Smartqueue_users) Deliverables

The user_nodequeue module will provide the following functionality:

1) Administrators can specify which user roles automatically receive nodequeues
2) When a user of a specified role is created, a nodequeue corresponding to that user will be created.
3) When a user is deleted, the corresponding nodequeue will be deleted.
- a) The module should prompt and warn the administrator before deleting the nodequeues.
4) Administrators can specify which node types should be available in user nodequeues.
a) Administrators could potentially be able to specify on a per-role basis which content types can be enabled in user-nodequeues. If this is the case, available node types for each user-nodequeue will consist of an aggregate of node types specified for nodequeus of that user's role.
5) An 'edit own user nodequeue' permission will be defined to allow for use cases where users cannot edit their own node queues, such as a list of selected content by a particular user that is maintained internally by website administrators\moderators.
6)The content of the user-nodequeue will display on the user's profile page
- a) The module will define a default view that is utilized on the user profile page
- b) Administrators can specify an alternate view that will control the display of user-nodequeues on user profile pages

The og_nodequeue module [2]

Drupal is widely recognized as a platform for building community websites and the Organic Groups module is perhaps the cornerstone community building module. Having a nodequeue for each organic group that is editable, group members would provide a new way for users to collaborate inside of sites that run OG.

1) When an OG homepage node is created, a nodequeue that corresponds to that OG homepage node will be created.
2) When an OG homepage node is deleted, the corresponding nodequeue will be deleted
3) Two possibilities:
- a) Members of the Organic Group and site administrators will be able to edit the nodequeue for that Organic Group.
- b) Administrators of the Organic Group and site administrators will be able to edit that OG's nodequeue.
4) The content of the Organic Group's nodequeue will display in a block defined by a view, provided by this module
- a) Administrators can specify an alternate view that will control the display of OG nodequeues
5) Administrators can specify which node types should be available in OG nodequeues
6) When an administrator changes sitewide settings for OG Nodequeues, these changes should affect all og-nodequeues, to the extent that this is programatically practical.

Project Schedule

(from the project proposal)

• May 26 – Begin coding user_nodequeue
• June 16th - user_nodequeue milestone: coding should be 50% complete at this point.
• June 30th – user_nodeqeueue milestone: Basic QA testing begins. Wrap-up coding
• July 6 – user_nodequeue coding should be complete
• July 7 – og_nodequeue coding beings
• July 28th - og_nodequeue milestone: Coding should be 75% complete at this point
• August 4th – og_nodequeue milestone: Basic QA testing begins. Wrap-up coding.
• August 11th – og_nodequeue milstone: coding should be complete. Begin final QA testing phase of both modules.
• August 18th – Final pencils down date.

Status Updates

5/27/2008

First substantial commit made to smartqueue_users.module!

5/31/2008

hook_nodequeue_subqueues implemented. SubQueues are now deleted when multiple accounts are removed at once. Modular access patch to nodequeue.module is not actually necessary.

6/4/2008

First status update according to the specified template:

1) Since the start of coding, I've laid down much of the foundation for this module. SubQueues are now created and deleted when accounts are created\deleted, can be restricted to contain the queue owner's content only, and "add to queue" links are being displayed properly.

2) This week intend to furnish most or all of the "batch update" functionality, where SubQueues are batch deleted, disabled, or created when the roles of users who should have SubQueues are changed.

3) I'm not stuck :).

6/10/2008

1) SubQueues can now be batch created and deleted, though batch delete still needs a confirmation dialog. SubQueues are now updated to reflect changes to usernames.

2) I think that with the batch-delete confirmation dialog and module-provided views for user profile pages, I can release a nightly dev version of this module shortly after the scheduled 50% code-complete milestone. That way, the community can participate in the QA process and I'll be a bit ahead of schedule. :D

3) I'm not stuck :).

6/17/2008

1) Batch deletion\creation was refactored to provide a confirmation screen. This turned out to be a larger task than expected and would probably have been best done at the time batch deletion was originally written. The module defines and places a User Node Queue view on user (profile) pages. Whether or not contents of User Node Queues display on user pages can be configured on a per-Queue (not per-subqeueue) basis. The module now correctly checks a new user's eligibility (by role membership) before creating a subqueue when the account is created.

2) As I found before the start of coding, no patch to nodequeue.module is required to enable modular access control for the queue manipulation links displayed in a node's $links array. However, I have discovered that in order to avoid a one-time semi-hackish solution for restricting access to the queue manipulation form, a modular access patch to nodequeue is required. Ideally, I'd like to get that into the issue queue by the end of this business week. Then the module would be ready for a nightly dev snapshot release to help enable community testing of this module during the QA phase.

3) I'm not stuck, though this week my patch could use some attention in the issue queue ;D.

6/27/2008

1) I've submitted a patch to nodequeue to enable modular access control of queues and subqueues. The patch is at http://drupal.org/node/272298 and I've revised it twice. I also proposed a solution to a problem some users are experiencing where changes made to a nodequeue are not visible to anonymous users because the page cache has not been cleared. This could be a good feature for me to add to nodequeue since it still seems that I may finish the deliverables ahead of schedule.

To quote part of my comment on that issue:

How about a configurable option for each queue where administrators can specify the maximum amount of time that can pass since the queue or any of its subqueues was is updated and the page cache is cleared. On each crun run, nodequeue could decide to clear the page cache.

Allowing each queue to have a unique lifetime allows changes to more important queues, (ie "Frontpage Queue") to be visible to anonymous users more quickly without clearing the cache each time a less important queue (ie "Joe User's personal favorites queue") is updated. Having it be cron-based prevents administrators from having to keep track of queue changes and clear the page cache manually.

2) I am going to comment on an issue in the queue that may be related to the patch review that I am awaiting, and get in touch with Merlin when I have done that.

3) If the patch is delayed further, I can simply start coding smartqueue_og.

7/2/2008

1) I committed changes to smartqueue_users to interact with the nodequeue modular access patch, which will probably be accepted shortly. I continued the discussion and revision of my patch to nodequeue. I also made some changes to the permissions in smartqueue_users to be more consistent with nodequeue.module.

2) This week I will finally issue a release of smartqueue_users with or without acceptance of the patch to nodequeue. There are a few mostly minor changes to make to smartqueue_users unrelated to the modular access patch and I plan to complete these as well. I'm moving to another apartment today -- this has slowed down coding somewhat but will be putting a larger block of time in later this week to compensate.

3) I'm not stuck.

7/4/2008

1) A first (and moments later a second) release for smartqueue_users has been created and is now available on the project page! The module now prevents users from creating additional (problematic) queues, and several other minor improvements have been made as well. The project page includes a screenshot of the queue_edit form. Merlinofchaos gave me commit access to Nodequeue.module, and I committed the modular access control patch. I agreed to port this feature to the D6 version of Nodequeue. Nice!

2) I will enthusiastically await feedback from testers of smartqueue_users and lay the groundwork for smartqueue_og .

3) I'm not stuck but I'm not clear on the requirements for testing. Since simpletest is no longer included as the core testing framework, what is the GSOC requirement for project testing? Thanks!

To-Do

-Create, delete subqueues as accounts are created\deleted
-Implement hook_nodequeue_subqueues, which defines which queues are relevant to a particular node.
-Batch create\delete\disable SubQueues (From nodequeue_users settings screen. Not triggered by hook_user create\submit\delete) (Batch delete needs a confirmation dialogue. Batch disable on a per-subqueue basis seems to be impossible with the current nodequeue API. )
- Update SubQueue names when usernames change.
- 6a) Define a default view that is utilized on the user profile page
- 6b) Allow administrators to specify an alternate view that will control the display of user-nodequeues on user profile pages
Admins can do so simply by creating a view with the same name as the one that is defined by default. This is the same way that a custom Organic
Groups homepage river of news view can be defined.

- Modular access to queue administration screen patch to Node Queue [Revised, In the queue at http://drupal.org/node/272298]
- Define the User Node Queue block [ minor change to the view]