This project is not covered by Drupal’s security advisory policy.

Running Case Tracker and Organic Groups on the same site raises some questions - but CTOG helps solving them by utilizing some rules to tie them together in a way which makes them easier to use.

Let's assume the following scenario. The site serves a central hub for several groups of people to provide an easy-to-use interface for storing information while working on projects and solving cases. The different groups are consisting of different people, and each group has it's own project to work on. The projects are separated from each other: no person of group A should be able to access any stuff of group B if s/he is not a member of that one as well. Additionally, no case can belong to more than one project at the same time.

This is where Case Tracker and Organic Groups are kicking in (referred to as CT and OG from now on). CT is quite a good choice to serve as an issue/case management system, but does not have anything to separate the different projects from each other. OG is the responsible for access control. So, let's use node type "Project" as a "project" node type speaking CT language and as "group nodes" speaking OG language; let's use another node type: "Case" as a "case" speaking CT and "standard group post" speaking OG.

What's wrong with that?

Basically nothing: everything should work as expected - but there are some issues, mostly affecting user experience (UX).

Let's have a look at the "Case" node type. When a "Case" is being submitted/edited, Case Tracker shows control widgets to choose which project should the case belong to, which user should the case be assigned to (if any), and so on. But wait, there are other control widgets to select the groups/audience the case should be displayed in - and even a "Public" checkbox! Here comes trouble: what should one select as the audience of the group post (speaking OG), given that any given case can be submitted to only one project (speaking CT)? Additionally: if I am part of group A with two colleagues of mine, why can I assign the case to any user, even ones that I do not know about, since they are only member of group B? While the OG group post (case) content type can be set up to allow only one group to be submitted to, why the need to select this group, if it has already been selected in the CT part of the case node form?

CTOG.module helps to solve these issues, so here is a short (and most likely incomplete) list of features. CTOG alters the node forms being both cases (CT) and group posts (OG) and their comment forms as follows:

  • removes the unneeded 'Groups' fieldset (both the 'Audience' multiselect and 'Public' checkbox),
  • ensures that the case can be submitted to only one group (OG speak),
  • ensures that the group (OG speak) of the node becomes the project that is selected as the case's project (CT speak),
  • changes the 'Assigned to' field to a simple single-select,
  • ensures that the node cannot be assigned to (CT speak) a user who is not a member of the project (OG speak) that was selected,
  • increases UX by some AHAH magic: if and when the project dropdown gets displayed/changed, update the list of available users in the 'assigned to' dropdown (CT speak) to the members of the selected project (group in OG speak).

In other words, CTOG simply adds some more rules to the CT and OG node submission handling, which are even stricter than the original CT+OG rules, but increases usability in the same time.

Dependencies

Case Tracker and Organic Groups. Drupal core's comment is not listed as an explicit dependency, but its forms will be altered as needed if enabled.

Development

Developed sponsored by KYbest.

Project information

Releases