Direction for Casetracker...

Hi,

I hope you'll pardon me waltzing in here with this big idea, but I figure it's better to put it out there and get shot to pieces than sit on it and not share at all. I've been doing a fair bit of work on your Casetracker module for a site I'm in the process of developing; initially, I was only planning on opening up a system so that Realms could be added/removed very much like States; I might have just manually added the necessary static Realm names, but I also wanted to allow for the possibility of having realms that allow for multiple State values. (Use case on the multiple states: for my implementation, it would be highly beneficial for me to be able to classify the set of programming skills required for a given task. However, since so many drupal tasks require multiple different programming skillsets...).

I've gotten a fair ways into adding the necessary modifications that allow for modifiable Realms, but as I do more and more work, I've begun to see a larger recursing pattern in the data Casetracker contains. My sense at this point is that taking some steps towards reflecting that structure in the code of Casetracker could do a lot to resolve the issues folks have raised (say, http://groups.drupal.org/node/7850). Lemme attempt to diagram out my thinking about that recursing structure:

First, there's the 'physical' tree; that is, the assortment of content types and the instantiation of those types as nodes (which I'm referring to as tokens in this diagram). Think of Case Types as being things like "Bug Report," "Feature Request," etc.; very much like the structure of http://drupal.org/project/project_issue; however, nothing prevents them from being something like a "Phone Order" if the parent project token is "Pizza Delivery."

Types/Tokens Tree

(Level 1)          (Level 2)                    (Level 3)
Project Token ===> Case Type 1 ==========> Case Type 1 Token 1
        |               |================> Case Type 1 Token 2
        |               |================> Case Type 1 Token ...n
        |========> Case Type 2===========> Case Type 2 Token 1
        |               |================> Case Type 2 Token 2
        |               |================> Case Type 2 Token ...n
        |========> Case Type ...n =======> Case Type ...n Token ...n

The big question, I think, has to do with determining what options are available (and to whom) at every one of these three levels. If this is done effectively, I think that you'd never actually need to define multiple Project types; every possible desired combination could be accomplished by simply allowing different options to be set per Project token. But, since the crucial piece of this is what those options are, here's another diagram that lays those out. Levels 1-3 below correspond to the levels in the Type/Token diagram above, although it's the combinatorial options that occur BETWEEN these levels that make the big difference:

Options Tree

(Level 1)          (Level 2)                                                (Level 3)
(Project Token) => (Case Types) ========================================> (Case Tokens)
        |                                                   
     DIRECTLY                                               
    DETERMINES ---> Case Types ---- DETERMINE UNIQUE INSTANTIATION OF ---> Case Token
     POSSIBLE           |                  ^    ^
        |               |                  |    |
     DIRECTLY       DETERMINES             |    |
    DETERMINES ------> ALL ----> Realms ---|    |
     POSSIBLE        ALLOWED       |            |
        |                      DETERMINES       |
        |                         ALL -----> States
        |                       ALLOWED         ^
     DIRECTLY                                   |
    DETERMINES ---------------------------------|
     POSSIBLE

Looking at that, I'm worried it's completely indecipherable, so here's a linear workflow picture, too:

Project Creation Workflow

1. User creates a Project Node, one required step of which is specifying which content types (that have elsewhere been marked as Case Types) are allowed for that project. This corresponds to that first 'DIRECTLY DETERMINES POSSIBLE'.
2. For each content type that has been indicated as being allowed, another selection is presented (either via AJAX, AHAH, a multi-step form, or some other method) that requires the user to indicate which of the existing realms marked as ALLOWED for that content type are going to be possible for this project's instantiations of that case type.
3. For each realm that has been indicated as being allowed, another selection is presented (again, either via AJAX...) that requires the user to indicate which of the existing case state children of that realm are going to be possible for this project's instantiation of that case type.
4. That's it! The project type is created.

Realm Creation Workflow

1. Realms are managed via some extra tabs at /admin/content/casetracker (this is some of the code I've already written).
2. When adding a new realm or editing an existing realm, a query is run to determine which node types have been marked as being case types; if we are editing an existing realm, an additional query is run to get any existing associations with node types and set default values accordingly.

Case Type Creation Workflow

1. Can use normal content types, e.g. things made by CCK, or whatever.
2. As with modules like nodeprofile or OG, configuration options related to Casetracker only appear on the content type configuration form once the content type has been flagged in Casetracker admin as being a case type.
3. Once marked as a case type, the edit content type form will display an additional tab that allows the user to select the realms that are allowed for that content type. Note that these are the same settings that are being presented in the realm editing type, only that here they're normalized with respect to the content type you're editing, instead of normalizing content types with respect to the realm you're editing.

Case state configuration works exactly as it does now, no need to change it.

A lot of the utility in setting up a system like this is that it fits like taxonomy like a glove...at least, as far as I can think it through, it does. One vocabulary per project type, with one first tier term per each content type and one second-tier term per each realm. Hmmm...well, the multiple parents issue may be a problem, but it still doesn't matter; all you have to do is programatically set up one term per content type that's marked as a case type, and one term per realm. No contortionist hand-written craziness has to be done to figure out the available realms & states for each project's version of each content type; one or two tables can store that data, and all you need for a lookup is the different associated taxonomy terms. The benefit of doing it with taxonomy, of course, is that your permissions system can be dynamic and need not crowd up the roles table. Plus, it makes hooking in with things like workflows a lot easier.

Anyhoo, I'm writing all this up here because I'm thinking I'd really like to see Casetracker move in this direction. There's a lot to be learned from Project* of course, and if this actually goes somewhere, possibly some benefits to be had for Project* as well. In poring through the Project code, however, Casetracker seems to be the place to start with this, as it isn't so tightly bound to the responsibility of interfacing with CVS, providing downloads and other things specific to handling code. And hey, since I'm likely to be implementing something like this on my site anyway, I figured I'd at least throw it out there.