Kaspersky Lab Use Case

Events happening in the community are now at Drupal community events on www.drupal.org.

In an attempt to create the most robust feature-set for this project. As many use cases as possible (but honestly, not a lot more than 10 or so--unless some are wildly different) need to be collected.

This is the use case I envision being able to use:

At our offices, we have a lot of changes that occur to our sites. Some are uni-directional, in that they alter one way and then stay that way; another is that they are bi-directional, in that they swap back and forth; and some are rotational, in that they always change, but never are the same as before.

An example of the first would be a change to content layout on an about us page. This typically will change once and then stay that way for some time.

An example of the second would be a monthly promotion, where a price change occurs, or a product bundle occurs and then swaps back after the promo has ended.

An example of the third would be featured content that is always changing.

**It is important to note that #2 and #3 are always scheduled.

Our Requirements

  1. Group revisions made to a group of nodes into a 'site revision'
  2. Browse the entire site by that 'site revision'. This is pretty huge as it will require views, etc... to all read the pending revision, and not the published revision.
  3. Scheduling of revision publication
  4. Scheduling of revision un-publication/reversion
  5. Multiple scheduled revision publications for nodes and node groups
  6. Ability to give a non-auth'd user a token or a key of some sort to view the site at a certain revision
  7. Ensure that even css and js and even tpl files can fit into the revision publication/un-publication (may need to work with versions in the Features module).

Modules that come close, or seem like the right, but aren't:

  • Features While we will make use of the Features module to encapsulate feature-esque updates and roll them out via SVN, this module is explicitly not designed for content, but rather configuration. It is possible that Features could be used to encapsulate and manage some portions of a revision publication.
  • Revisioning This module gives some of the things we need, but it cannot group a set of nodes into one revision
  • Content Moderation This module is a good start, and may be able to be integrated into what this group hopes to acheive
  • Actions/Triggers, Rules, Workflow All of these modules/systems fall short of the goal I have because all of them are designed to work with single nodes/data objects, when I need something that will work across many nodes, data objects, and even assets.

As I noodle through this more I'll refine this Use case, it's requirements and possible modules that could be a part of a solution.