Drupal 8 Case Tracker [#2560519]

Problem/Motivation

The Case Tracker module has undergone several maintainer changes some of which has precipitated a change in direction. The As we start the port to the Drupal 8 version, I'd like to take casetracker a bit back in line with its original direction. This issue has been created to facilitate discussion on the approach as well as track work towards the Drupal 8 release. Please feel free to comment on this issue regarding thoughts on the future of casetracker.

Here are some issues from the past:

Having used the casetracker module for more than 5 years from Drupal 5-7, here are some basic ideals I'd like to maintain:

New system should be relatively turn-key enabling the casetracker_basic module should give you a functioning issue tracker.
The case tracker should work well for software development, but also as a general issue tracker.
Integration with rules, actions and views is essential.
We should provide some method of reporting on case metrics.

Proposed resolution

Given that Drupal 8 will require migration rather than upgrading, lets rethink the approach from the ground up. Here's what is currently being envisioned:

Issue statuses including issue status and assignement and whether the issue is opened or not will be tracked in a custom field type.

Remaining tasks

We still need to determine whether the projects are essential to the DNA of Case Tracker. On the one hand this was the inspiration for Case Tracker, but on the other hand there have been attempts over the years to attach casetracker entities to things like Organic Groups, and the integration points have been a bit difficult to achieve because of the way the module ties so deeply into the concept of projects.

Comments

Comment #1

31 August 2015 at 16:59

metzlerd created an issue. See original summary.

Comment #2

metzlerd CreditAttribution: metzlerd as a volunteer commented 31 August 2015 at 16:59

Issue summary:

View changes

Comment #3

metzlerd CreditAttribution: metzlerd as a volunteer commented 3 September 2015 at 22:58

Version:

7.x-1.x-dev

» 8.x-1.x-dev

Comment #4

pedrorocha CreditAttribution: pedrorocha commented 10 September 2015 at 19:58

Regarding having a project or not, I think that the question is more about allowing entity types to become projects than to remove the concept of Projects inside the module.

The same way OG allow us to make any entity type become an OG, we can also allow any entity type to become a Project. If we remove the concept of Projects, we'll end up with a todo list, that is not the goal of this module.

Comment #5

metzlerd CreditAttribution: metzlerd as a volunteer commented 11 September 2015 at 18:20

Yes, your thoughts mirror my own on this. I wasn't really suggesting "no project" but rather how to structure the architecture such that it supports the idea of projects or multiple kinds of projects. Sometimes it's helpful to slice issue queues in different ways. Many people use the terms product and project interchangeably, but I think of them as different things. A project is a time limited effort with funding/etc to accomplish a goal. A product is a piece of technology and has code boundaries around it. I'm reaching for a system that might let you choose which way you'd prefer to think of your issues.

My current approach is focused on creating a composite field type for an issue/case that includes assignment, status and priority. The field would include appropriate logging of history for the changes in casetracker state as well as firing rules events if/when that code becomes available. The casetracker_basic module would expose node or entity types with appropriate fields attached. I'll make an 8.x-dev snapshot available when I have this minimal work done. (I've created the 8.x branch already).

I've experienced some tools that suggest products/projects are hierarchical, so the best kind of native entity type for that might be taxonomy terms. But I'm not that far along in the D8 development process yet, so I'm still thinking about this. Thoughts on this might be helpful. One tool I've seen lets you define case states priorities etc on the parent project and have them available to all child projects... it's a really interesting approach.

Comment #6

CatherineOmega CreditAttribution: CatherineOmega as a volunteer commented 18 November 2016 at 15:38

I'm inclined to not group by project, but instead, allow a set of cases to be attached to something, be it a group, a different kind of node, or whatever entity. That would make it a lot more flexible--and yes, I've run into the project issue before as early as 6.x personally.