Jump to:
| Project: | Case Tracker |
| Version: | 7.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
We discussed a lot in #1653184, so now it's clear that the Entity based approach is good, but how do you think that this should go on?
Actually, what i think about what the module should accomplish is(i'm talking about end user goals):
Simple use cases
* create different types of projects (future proof, enabling people to improve without many problems)
* create simples projects (title, description)
* create different types of tasks (future proof, enabling people to improve without many problems)
* create simples tasks (title, status, created date and completed date - status changed -, maybe a simple way to create a description field)
* overview which projects do you have with tasks in each statuses (for people who just want to know what they need to do right now)
Intermediate complexity use cases
* create tasks with "due date"
* discuss over tasks, with something like comments
* overview of tasks that need to be done soon
* milestones
* receive notifications about changes and reports via email
Complex use cases
* comment driven updates
* update tasks via email responses
* gantt chart
* Scrum board
Any other ideas?
Comments
#1
Project timeline would be great too, using the Message(a good thing, because Message Notify would help with the notifications about project/task changes) module or something like that.
#2
I agree with the simple use cases, but I would make the status and all associated overviews part of a features-feature that defines practical project and task types as the status definition can vary wildly depending on the real-life usecase (bugtracking vs. end user support tickets and so on).
Generally I would focus on building a solid base in providing good views and rules integration to enable users to build features like a project timeline themselves or use a contributed feature to enable this kind of functionality on their site, instead of adding this as defaults to casetracker module.
As to message integration: In combination with message-subscribe and flag you could basically build an e-mail notification system that is rules driven, so I guess a good rules integration would cover this aswell.
The only things I would add as optional modules in the casetracker module are the comment driven updates and a ui to quickly create project and case entities with ajax, as this has to be modeled closely to the entity structure.
#3
I agree that many things could go on features, for the same reasons you said, but status is needed in even in the most basic situation with a cases/tasks. We need to make it flexible, however. A good approach is how Drupal Commerce treats the Order Statuses, in a pluggable way, with State and Status, with hooks so that other modules entend it.
About Comment Driven, we have a problem here, because neither Comment Driven itself or Driven API were ported to D7. Despite agreeing that it's a good feature, i'll not have the amount of time needed to take care of so many modules(Case Tracker, Reply, Driven API, Comment Driven) and integrations(Rules, Messages, etc). Would be great if someone could help with this driven related stuff, but as this isn't critical for the other parts to become useful(not every use case needs it), i think that we can go on and maybe in the future, integrate with some new module/version of these modules.
#4
I agree with your take on the status. I don't know how commerce handles this, but I'd basically add a configuration interface where you could map the predefined states of a project / case to a status that is defined in a taxonomy reference field. An approach with hooks also sounds good to me, one can surely borrow a few best practices from commerce here.
I could look into the matter of comment driven update process. The big plus if we stick to the status-as-a-field approch would be that we could maybe make a more generic module out of this, where optionally all fields of an entity are exposed.
As entity api already provides crud integration for rules, we could build a basic feature that generates messages on those events anytime. We should add rules support for setting states though. (So that for example if a project gets state closed, all associated cases could also be closed automatically).
#5
@pedrorocha: For complex use cases, you should really consider some rules integration. This would allow for actions taken on a website to automatically trigger tasks and/or projects. I want to distinguish a clear differentiation that this is not meant to simulate support center functionality, but rather to allow for the more business friendly approach we have previously discussed. With such rules integration you could simulate most of the functionality of most CRM's but with a significant performance advantage, in that, leads, invoices, account follow ups, ect, could automatically become tasks/projects and be assigned to specified users.
I believe this is all fairly straightforward and possible with rules without really any additional functionality being needed. All that would be required is to set up the initial actions and events to be able to set the tasks/projects (Complex Use), set a due date (Intermediate), and assign a user (Simple use). Other functionality such as email and the like are already available to rules and could significantly decrease development time.
I also agree that the Message Module could be a very nice fit, as it will allow for the proper and NEEDED tracking of progression that most use cases require.
Just a few thoughts.