[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