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]

7/18/2008

1) After asking Merlinofchaos a question about how to best forward-port Nodequeue modular access control to the Drupal 6 version, I started working on the forward-port patch, which is in the queue at http://drupal.org/node/278609 . It needs further testing and revision, and I would very much like to complete that this week. I discovered at least one apparent bug in the NQ6 RC, which I haven't filed yet, but hope to address as part of the patch in the modular access issue.

I spent some time in #Drupal and reading documentation to get up to speed on the new menu system, and based on a conversation with CHX, had a line added to the menu system documentation to make it easier to understand. ". %foo means foo_load will be called" was added to http://drupal.org/node/109153 ;).

I created a 6.x development release for smartqueue_users, and feel comfortable continuing development of smartqueue_og with Drupal 6 as the primary version. I found that I will not have to patch Nodequeue to allow differently labeled add and remove links for different subqueues, because this was already taken to account when Merlin designed the API (of course).

I found some bugs in the initial releases of smatqueue_users, fixed them, and made new releases.

Since we were anticipating possibly having extra time when the project is left over, it occurred to me that an additional feature for smartqueue_og would be to allow users to restrict the contents of group node queues to posts which are already in the group. This shouldn't be too big a deal to implement.

2) I would feel a weight off of my shoulder if I could complete the forward porting of Modular Access control to Nodequeue 6. It's taken me longer than expected to make progress on this part of the project, and it would be great to develop smartqueue_og in Drupal 6.

3) I'm not stuck, but will have to devote more time to the access control forward port.

7/30/2008

[updated 7/31/2008 as apparently I didn't save my latest revision.]

1) I finished and posted the nodequeue 6 modular access control forward port patch, and it is currently awaiting review. Smartqueue og now fulfils basic functionality (smartqueues are created for the correct group node types and users see the correct add and remove links based on their group membership.

I spent a significant portion of my GSOC stipend flying out to DrupalCamp Colorado. Thanks! I attended the Simpletest session and feel more comfortable about writing tests for these two modules. (I also presented on performance and scalability.)

Smartqueue_users seems to be mostly updated for Drupal 6. I answered a support request for that module but haven't gotten a response yet about which PHP version the user is using.

2) It seems reasonable to finish the basic requirements for smartqueue_og in the next 7 days.

3) I'm not stuck.

[update based on 7/31/2008 progress]

Smartqueue_og can now determine whether to display add/remove links based on a user's group membership status (member or admin), and queues can be configured to be restricted to only posts which are part of that group. These settings are currently hard-coded as a proof-of-concept and will be configurable soon.

I've submitted a patch for a bug report to smartqueue_users. For the latest, see the smartqueue_users issue queue.

08/13/2008

1) While Merlinofchaos previously granted me commit access to Nodequeue, he recently made me full co-maintainer to Nodequeue! His guiding advice was to keep in mind the 3% of edge cases that might be harmed when making a change to the module. While 3% might seem like a small fringe number of users, this number is probably significant when a module is amongst the most frequently used contributed modules.

With this in mind, I devoted some time to cleaning up the Nodequeue issue queue. I answered and "fixed" support requests, closed old issues, reviewed a patch or two, reported a new bug and identified bug reports that shared the same underlying problem for which there was already a patch in the queue. My modular access control forward port patch was finally reviewed (Thanks, Kevin/cyberswat!) and I will run through the detailed testing steps he performed to see if I get the same results. I expect to put out the next Nodequeue 6 release candidate in the next week or so.

And now, back to our regularly scheduled Summer of Code:

The deliverable features are in place for Smartqueue_og, including the "maybe" features from the proposal: A "this group's queue" block can display on group homepages, and administrators can configure whether group members or only admins can manipulate the group node queue. Queues can also be restricted to include only nodes that are part of the group. The default View for smartqueue_og is now in place as well.

Both the smartqueue_og and smartqueue_users default Views now filter by queue id in addition to reference, which will prevent nodes from the wrong queue from showing up when two subqueues have the same reference. Of course, Merlinofchaos included a qid option inside of the reference filter, so that an additional View filter is not required.

I released a new version of smartqueue_users that addresses a couple of bugs that I identified in my own testing and that users in the queue identified (One user submitted a feature request to nodequeue for the functionality that smartqueue_users provides, and I directed her to smartqueue_users ;) ).

Recently, this module has started to see more activity in the queue and thanks in part to the most recent test user, I've submitted several feature requests which I'll add to the module to make it even better. For example, administrators see add/remove links for all subqueues to which they have access -- This can quickly get out of hand on a site with thousands of user-queues. I plan to add a feature to restrict the number of add/remove links that administrators see.

2) On my agenda for the end of the Summer of Code:

• Release a new Nodequeue release candidate (Maintaining nodequeue isn't technically part of my SoC project, but it's related enough that I'm listing it here.)
• Add essential features (such as the restriction on the # of add/remove links that admins see for both smartqueue_users and _og.
• Simpletests, Simpletests, Simpletets!

3) Having even just a few pieces of feedback on smartqueue_users has been extremely helpful to improving the module. I'll probably need help at some point with simpletest. Here's to pushing through the end of the Summer of Code (and beyond)!

08/17/2008

Final Status Update:

Nodequeue.module:

I rolled a new release candidate for the Drupal 6 version of Nodequeue, which finally includes my modular access patch which I re-rolled to address a related issue reported by coltrane. I found a minor bug in the Views 2 support, created a Drupal.org documentation page for Nodequeue and added a definition of 'subqueues.' I'm pleased that the 2nd RC is out, and it's great to see lot's of green in the nodequeue issue queue. I am confident that we will have a full release soon.

Smartqueue_users.module:

Smartqueue_users has had a few new releases for Drupal 5 and a Drupal 6 alpha, which should be roughly equivalent to the D5 version. Smartqueue_users got much more attention from test users than Smartqueue_og, and as result I was able to build new features that users suggested. The latest release fixes a "bucket O' bugs'" and has two new features, suggested by users, which I think will make the module much more valuable for sites with large user bases: Queues can be configured to hide add/remove links for other users from administrators. Previously admins would see all links to which they have access. This is impractical for sites that have large numbers of users. Also, two new permissions were added for viewing user queues on user profile pages, making it easier to have private queues. Smartqueue_users also makes better use of the Nodequeue API by using the smartqueue_api_submit_finish function to batch generate user queues. This hook, like it sounds, is called after the queue has been saved to the database. Initially, user queues were being saved with qid of 0 because batch creation took place before the qid was assigned in the database. My solution was to disable batch creation until the 'edit queue' form had been submitted and the queue was created, however I realized shortly after implementing this minor change that the _submit_finish function was a more elegant solution. It goes without saying, but Merlinofchaos did an excellent job with the Nodequeue API!

Smartqueue_og.module:

Smartqueue_og has a new release, and hopefully users will test it and provide feedback. With Nodequeue 6's support for modular access control, I can update Smartqueue_og to Drupal 6 in the near future.

Simpletests:

I encountered some rocky territory here.

I spent the majority of the Summer of Code developing in D5, mostly because my patch to NQ6 hadn't landed yet. Because my modules supported D5, I started trying to write Simpletests for Drupal 5. This was not so Simple. After spending hours trying to get Drupal 5 Simpletests to work properly, I got the message from community members that automated testing for Drupal 5 is mostly a lost cause.

I updated Smartqueue_users to Drupal 6, wondered why my tests weren't working, found out that I needed to update my tests, updated my tests, encountered other errors and submitted a patch to the Drupal 6 and 7 Simpletest module to clarify the message displayed when simpletest can't find the forms that are requested (this was marked a duplicate of http://drupal.org/node/293099). At this point, I decided that my siginifigant investment into writing Simpletests by the end of SoC was no longer a good use of time. At this point I discovered a couple of additional bugs in Smartqueue_og and fixed them.

I'm thrilled to have had the opportunity to develop these new modules and I look forward to maintaining them (and co-maintaining Nodequeue) in the years to come!