[consulting] Issue tracker specs

Morbus Iff morbus at disobey.com
Thu Oct 26 19:32:32 UTC 2006


> I've just been re-reading your notes and your design seems very elegant.
> If you don't mind me asking, what do you mean by 'making a CCK project
> type an Organic Group'?

Allow a long-winded explanation, most explanatory pre-history.

First off, I always future proof my installations. To "future proof" 
generally means "I am currently an idiot. I can not see what I will need 
five years from now. Therefore, I should make the most flexible decision 
RIGHT NOW, even though I don't know if I'll ever use it."

Consider, today, that the only thing you need for a project is the title 
("Client A") and a body ("Client A rules!"). Since you only need these 
two things RIGHT NOW, you may say "well, hell, a regular old Drupal 
'page' could be a Case Tracker project because it does everything!" You 
then go ahead and, over the course of 4 years, make 300 projects - that 
is, 300 'page' node type that are Case Tracker projects.

But, coming around on 5 years from now, you decide, "you know, it'd 
really be useful if I included some contact information on each of these 
projects, because I'm getting quite confused on who the contact person 
is, or what their website was." But, because you chose Drupal's 'page' 
node type, you don't have this capability - 'page' ONLY has title and 
body, and you can't add anything more to it [1]. Suddenly, you have to 
decide if a) you want to write an upgrader/converter for all 300 'page' 
node types or b) if you can live without the feature.

Thus, for everything I do, I always start out with CCK. Today, right 
now, I may create a custom CCK node type called 'monkey'. It will 
contain only the title and body that I need today. But, if five years 
from now I want to add some URL fields, I can - because it's a CCK node 
type, and that's what CCK node types are designed for: customizing.

So, that's why I start with CCK.

Now, a lot of Drupal modules allow you to "value add" (consultant-speak 
here) to existing node types. For instance, Organic Groups allows you to 
either a) use their existing "og" node type, which has the same problems 
described above - an inability to modify the fields five years from now, 
or b) "value add" to an existing node type, which allows Organic Groups 
to add its own features and fields to a node type of your choice. Lots 
of modules do this - event.module provides it own basic node type or can 
value add one of your own creation and, now, so does Case Tracker (for 
both projects and cases).

So, with the 'monkey' CCK node type I created in my awesome example, I 
can say to Organic Groups: "you know, instead of using your provided 
node type, I want you to use my 'monkey' type instead." This will cause 
Organic Groups to treat 'monkey' nodes as its own - it will add some 
Group related fields such as "Subscription options" and so forth. This 
is "value adding" to an existing node type, in this case, 'monkey'.

But, you don't need to stop there. We've got our CCK node type 'monkey' 
(CCK to future proof it for us), and we've made it an Organic Group (so 
as to get all the OG features). We can also have Case Tracker treat a 
'monkey' node type as a Case Tracker project - now 'monkey' is both a 
CCK node type (infinitely flexible), an Organic Group (with subscription 
options and other OG features), AND a Case Tracker project. All three 
modules will take this lowly 'monkey' and make it better.

Thus, our 'monkey' node type:

  * allows new fields to be added to it (CCK),
  * is an Organic Group with subscription options (OG),
  * is a Case Tracker project that cases can be assigned to.

These combine to create the following previously unavailable feature:

  * cases assigned to a project can only be viewed by subscribers.
    This happens because OG's node visibility controls what appears
    whenever you create a node assigned to a particular Group
    (which is what'd happen when you create a Case Tracker case
    assigned to a particular project which, as we've established
    earlier, is also an Organic Group).

Maybe I should make a diagram of all this? ;)

/How/ you do this configuration is via the settings - under both 
admin/settings/og and admin/settings/casetracker, you tell the modules 
which node types you want them to value add. Some modules have this 
actual configuration in a different location (such as event.module).

The above design can be applied to other node types, as I've mentioned. 
  I am testing "milestone" equivalents via a custom CCK node type (for 
that flexibility), assigned as an event (for the date options), and a 
Case Tracker case (for the priority/assigned to/state) options. This 
allows this case to be part of a project (with all the OG visibility 
goodness), but also to be shown in a calendar (with all the event.module 
goodness, like iCal export and other modules that themselves value-add 
to event.module, like rsvp).

I hoped I explained that well.

[1] Ignore, for the sake of my future proofing argument, that
      Drupal 5.0 WILL allow you to modify the 'page' node type.

-- 
Morbus Iff ( i've eaten fruity pebbles with p-diddy )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus


More information about the consulting mailing list