Using PFT to build PFT from scratch: roles

Again, functionality of PFT will be based on its own genesis. That means that I will create the functionality of PFT according to my concrete needs in wanting to use an agile approach to its building.

So far, I have implemented the project business object, and have used that to specify the project and added functionality for each authenticated user to be able to flag the projects she is working on and to be able to see them towards the top on the homepage.

According to the process we are following for website application development, based on Chapter 1 of my book Leveraging Drupal: Getting your site done right (available for free download here), I now need to specify the roles: the actual users who will be interacting with the website application.

Of course, in order to actually create the project content, I already created Drupal authenticated user roles for them. Since Drupal is its own best prototyper, it is also in this case.

However, since roles need to be defined and constitute the actor in each of the user stories we will need to specify the functionality of the webapp, we do need to have a content type created for them.

Here I did the following:

Decide upon architecture for drilling down node trees

Support drilling down from the project to the roles associated with it

Create the role content type

Create the actual roles for the PFT project

Build info

Support drilling down from the project to the roles associated with it.

Here it is necessary to determine the architectural baseline of how we are going to support relationships between nodes. I have used the Node Family module in the past. But no version is listed as available for Drupal 6.x, and no date is set for that.

Alternatives:

With Node Hierarchy, it would be possible to integrate with pathauto for hierarchical and intuitive URLs reflecting the hierarchy.

i.e. project/projectname/user-stories would show all the user stories.

Testing Node Hierarchy

I installed it and decided to try to make two pages and four stories and see if I could assign stories to pages, especially if a given story could be the child of more than one page.

Nope, no go; a given node can be the child of one and only one parent. As seen in the next section, we need a node to be able to be the child of multiple parents. I regretfully ripped out the module and restored the database image to how it was before I started testing.

Testing NAT

How would NAT work anyway?

To make a hierarchy of Story's "in" a page, one way might be the following:

  • Create a Pages vocabulary (like a Features, an Iteration, a Release, where Iterations and Releases are going).
  • Configure the Page vocabulary to categorize Story nodes
  • Configure NAT so that whenever a Page is created, a taxonomy term is created in Pages with its Title (and removed when the node is deleted).
  • Create a page "test one", and another "test two".
  • Confirm that the appropriate terms are automatically created.
  • Create several Story nodes "assigning them" (or not) to the appropriate page container (i.e. taxonomy term of vocabulary Page).
  • Make a view to show the relation
  • Yes! Sweet! light! clean! Click on taxonomy term "Test two" and you get a river of stories associated with that term, of course.

 

To implement a set of Roles belonging to a Project:

  • Install pathauto+global redirect to get taxonomy terms with cool configurable urls
  • Install NAT module

Create the role content type

  • Create a simple Role content type (Name and Description (title + body)).
  • Create a Project Vocabulary to contain roles
  • Configure NAT to relate project nodes to the Projects vocabulary.
  • Sync so that the existing projects appear in the proper vocabulary.

Create the actual roles for the PFT project

  • Create the roles for this project, assigning them to the appropriate project in the Project vocabulary.
    (Later on releases can also be assigned to the same project, with the Projects vocabulary set to contain releases, and features for that matter in the same way, as well as roles now.)
    • Product owner
    • Team leader
    • Team member
  • With the Acquia Marina theme this works out really cool because you can configure each vocabulary to appear on its own separate line, so you can see which project, etc. and... when you click on the project you get a list of the roles in that project! Cool!

TODO: some kind of tree display (taxonomy tree, term tree...?)

We've practically got our "drilling down" architecture all sewn up, and without those pesky node reference thingies also!!!

Build info

State: Changeset #16 (see http://awebfactory.svnrepository.com/pft/trac.cgi/log/ changesets 13-16)

 

Edit: 2009-02-25

  • Node Relativity: could be cool, but stalled in all its 6.x branches.
  • Node 2 node (yes: allows many to many relationships AND semantic role names)

Turns out to be exactly what I am looking for here. Have to write a views handler, tho; but light, simple as sin and dead easy to use. And shows really cool relationships, plus navigational node to node links...