Hi guys,
after 2 years seeing Case Tracker in Open Atrium, one thing that i always wanted was to be able to create "types" of tasks(cases) and projects.

In these 2 years, i used Redmine during a lot of time, and tested some other project management tools, because i never found one that really fits the flexibility that Drupal gave me, but a simple solution in Drupal wasn't available neither, needing a lot of modules bundled to achieve something reasonably usefull. Open Atrium is the best approach toward it, in my opinion.

In simple words: is complicated to setup a project management solution in Drupal. Open Atrium is the best one, from my point of view, but he is 2 to 3 years old, so we have a lot of cool stuff to improve on the path that he started, creating something simple and effective for many use cases(related or not with software development).

With Drupal 7, Entities and some other Drupal stuff, i saw that a really good turnkey and still flexible solution can be created, so i started to code some days ago.

So, let's go to what really matters.

First of all, node are gone. I created two Entity Types: Project and Task

  • Project Entity Type - with this, we can create different types of project, that could be Website, Architecture plant(why not use it outside techonology?), Marketing campaign, and many other "project types", each one with it's own fields, but everyone still being a Project, so that we could work in a lot of interesting ways
  • Task Entity Type - i always thought that a Bug report, a Feature request, and many other types of Tasks, could benefit from being able to have different fields. The same way as i told with Project above

With this flexible base, i think this will be a good starting point for modules like Scrum Taskboard, Kanban, etc, because all of them runs on top of Projects and Tasks. Two modules that inspired me a lot was http://drupal.org/project/atrium_scrum and http://drupal.org/project/ct_plus, because i think that Drupal still lacks a simple solution for Gantt and Scrum management tools.

I'm working hard to mimic most of Case Tracker 1.x approach, that is really good, with the "summary" tables with the entities too, and some usability issues.

What do you think of this? Is a good way? Do you think it will be usefull at all or i am overestimating?

p.s: sorry for any kind of "bad english spoken" in the message

Comments

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost commented

Task Entity Type - i always thought that a Bug report, a Feature request, and many other types of Tasks

Suppose it could lead to troubles with changing Task from oone type to another. Because each bundle could have different fields assigned

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

I understand your point of view, but after working with Redmine, a great project management tool that works this way, i realized that this is really usefull, because we can have good information about each type as fields, not in the "Description" field(each field has his own semantic value, context, etc, instead of just a big textarea).

I agree that this will force you to plan a little while before inserting some task, because, as you said, it could led you to troubles to change the type. This a differente approach from the "let's make all generic" to an approach where we have a better tool, that can gives us more potential, but needs some rules to be followed.

And, by the way, you can create another Case Type with a field "Type", if you wish. This is the real goal in make all of this with Entity.

And, if you wish, you can check the development, because i create the 7.x-2.x branch today: http://drupal.org/node/1655544

johnv’s picture

johnv
Primary language Dutch
CreditAttribution: johnv commented
Version: master » 7.x-2.x-dev
discipolo’s picture

discipolo CreditAttribution: discipolo commented

am i missing something here? after creating a case there is no commenting? no commentdriven or anything? how am i supposed to work on cases?

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

@discipolo, i'm thinking and searching a lot about the dependency of comments for Case Tracker, and i have 2 things to say:

1 - we didn't really need it as a dependency
In many use cases i've worked on, being able to simply add Cases/Tasks, without commenting, and relate them to a Project is the ultimate goal. This being said, i'm working in Case Tracker 2.x with this "simple tasks" as my base point, and some submodules that will create other types of Cases, and this comment driven approach will be there.

2 - Entities doesn't have support for Comments yet(not a stable one, at least)
Even if i wanted to do this now, there isn't a simple solution. Searching on how to make this "comment driven Cases" in Case Tracker 2.x, i saw some usefull links:

I don't know if Reply will be the best answer to this question, but i'm looking for a solution on this. Inclusive, if you have some idea, would be great ;)

johnv’s picture

johnv
Primary language Dutch
CreditAttribution: johnv commented

Regarding "2 - Entities doesn't have support for Comments yet"
What happens if you create a Node type for the entity-to-be-commented? That'll work.
Later on you can convert the Node type (also: Entity type 'Node' with Bundle 'foo' ) to its own Entity 'bar', keeping the Bundle 'foo'.

joel_osc’s picture

joel_osc CreditAttribution: joel_osc commented

I have been using casetracker for years managing help desks at various companies and have always thought that it was a fantastic module. I have a few concerns with the current architecture, similar to the ones expressed above:

1. Comments: this is a real issue, without a solution for comments I cannot deploy it. If I understand @johnv above he is suggesting using entityreference to link comment entities to their master case. This may be a workable solution if you use entityreference_prepopulate to take the master entity id and populate it (as well as hide the field) into a reference field in the comment entity. Display of a case would to me then involve a panel node override with the upper region showing the case fields, and a bottom pane with a view showing the node comments.

2. Entity types for Feature Requests, Defects, etc.: When deploying casetracker I usual end up adding quite a few fields to tailor it to the client business process. Having different entity types does add flexibility, but seems to me that it would create more work. I would be tempted to use something like Conditional Fields to provide customization per case type.

3. I have noticed that the entity fields are being created as locked (not editable), which presents an issue when a user attempts to change a default value such as enable 'assign to' to render as a select list in views exposed filter or other features like entityreference_prepopulate which are enabled through field edit.

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

@johnv, i didn't understand exactly, but, form my point of view, Cases and Projects shouldn't be Nodes, because the aren't exactly a content type, so i'm trying to find out a way to do the comments work with an entity.

@joel_osc, i didn't understand that he was saying to use entityreference, but if it's the case, i think that maybe could be an "alternative solution", temporarily, but not a definitive one, because my goal here is to make this module a solid base, but without depending on many other modules, only when really necessary, to simplify for the end users. But i do agree with both of you that case tracking, for a lot of usecases, fundamentally needs commenting feature.

About your number 2, as i said in #2, you can create another Case Type with a field "Type" and your specific fields, if you wish. This is the real goal in make all of this with Entity: be totally flexible. But while i'm studying the definitive implementation path that i'll take, it's becoming more interesting to have only one Case type created initially, like the old one, with the Type field, to be easier for the ones used to the old version.
About the field being locker, you aren't able to edit it, but you can change the widget to use unlike you said. Did you tested it and wasn't able? I tried here and seems ok.

The question in this locking is to prevent from this basic field from being removed, as i plan to create some reports for the module that will ultimately need that these fields be there, like schedules, etc.

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

Hi guys, thanks for the comments. It's helping me a lot in shaping what this new branch will be(unfortunatelly, i don't have the answer to the comments question yet).

I made a big change in the last commit, that will probably break if someone try to simply upgrade the files of this 2.x branch and use. I was comparing some modules that use Entity API to benchmark, and after that i decided to reorganize the stuff inside the module, and i took to retake the approach from 6.x module, to have a "Basic use" submodule, so will make it easy to have this "basic case type" that you are asking, along with the flexibility that i'm looking for with the Case and Project Entity Type approach.

ATTENTION: there is some weird problem with modules dependencies, that if you try to install casetracker_basic directly, bringing casetracker as a dependency, the installation process will not find the "entityreference" module to use the respective field type. To install without problems, you need to first install "casetracker" and, after the module installation being concluded, install the "casetracker_basic" module. If someone knows how to solve this, please give me some insight.

johnv’s picture

johnv
Primary language Dutch
CreditAttribution: johnv commented

Pedro, keep up the good work.

Perhaps we should create new issues for dedicated subjects, such as comments. For now, I've investigated alternatives:
- Entity node comment (sandbox)
- http://drupal.org/project/commentfield (better not us it, but it project page points to: )
- http://drupal.org/project/reply
- http://drupal.org/project/message (since this will be in the Commerce Kickstart profile, you'll get lots of Drupal Commerce co-maintainers!))

You might consider to design the 'Project entity', as a Vocabulary, since they are fieldable, too. Then, it can easily be shared between other features of websites. IMO a project is less a 'thing/entitiy', and more a grouping tool.

archnode’s picture

archnode CreditAttribution: archnode commented

Wouldn't it be logical to use the revision system (Entity revisions discussed for Entity API http://drupal.org/node/996696) rather than the comments to change node properties?

One could argue that not all comments would change the original node, so maybe a combined approach would be in order where one could select if a comment creates a new revision for the commented entity. We could display the revision messages per default and integrate comments if enabled.

JMOmandown’s picture

JMOmandown CreditAttribution: JMOmandown commented

Two modules that inspired me a lot was http://drupal.org/project/atrium_scrum and http://drupal.org/project/ct_plus, because i think that Drupal still lacks a simple solution for Gantt and Scrum management tools.

@pedrorocha: so does this mean you are wanting to leverage these types of functionality or are you sticking with your later comments about a minimalist approach with reference to your responses to the comments module?

I only ask because I agree 100%. In the past we have had to heavily modify Tracking modules to get the right fit. A lightweight internal solution to manage employees at the lowest level while presenting and high level projection chart (scrum) to the upper divisions. I feel as though these projects most of the time neglect to keep in mind the general business community and how they would use and manage an employee base with day to day, short term, and long term tasks.

With reference to these businesses, we tend to go from neglection to absolute overkill. Your comments suggest a nice middle ground. I commend you for that and hope that you may keep that vision moving forward. With that said the minimalist approach is a good one but I highly suggest extending the feature-set to include some of those covered by scrum and plus. This should actually be very easy with the entity approach since it really just becomes an installation profile at that point. Simply put just pre-installing the proper fields and date types then pre-defining views to feed the information to a graphing module. I know you said no dependencies but I think is definitely one to greatly consider.

Just my two sense from the Business perspective.

drupal a11y’s picture

drupal a11y CreditAttribution: drupal a11y commented

Great to hear this new approach. Keep on!
I am currently also on "research" and could help you with ideas, testings, design & frontend-design if necessary.

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

2012 was a busy year, but it's time to move this thing up!

As we can see in #731724: Convert comment settings into a field to make them work with CMI and non-node entities, Comment decoupled from Nodes will be, maybe, for Drupal 8 only and the modules pointed in this thread(http://drupal.org/project/commentfield and http://drupal.org/project/reply) aren't actively maintained, so they still needs some work.

@JMOmandown, i'm exactly with this "more business oriented" thing in mind, because i have some clients that only needs cases with Titles, without body, comments, etc, but the reports and dashboards would be great, so it's clear for me that this separation must be contemplated, and that's why the entities is the perfect choice. Good to see more people agreeing with this.

@archnode, i'm not used to case tracking systems that rely on editing the body itself, without Comments. Do you have any example of this approach?

@mori, any help would be great! If you have some ideas, get in touch.

Well, from the options listed, i think that Reply module is the way to go, so i'll try to get in touch with the maintainers and see how they can help, or maybe see if i could became a co-maintainer there.

To better define what we want the module to do, i created #1893138: Defining Case Tracker use cases: how do you expect this module to work?.

sigveio’s picture

sigveio CreditAttribution: sigveio commented

Thought I'd make you aware of this one: #1923892: Consider merging with Case Tracker

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

Long time passed for this, as i was a little frustrated with the lack of comment support, thinking that it will need an extra amount of work... but after some months using Jira and other tools, i'm really focused on creating our company internal project management tool with Case Tracker and then we started this week to work hard on it, starting other project that extends to work with Scrum: https://drupal.org/project/scrum.

The Entity based approach proved very good for this kind of extension.

We are working with these 2 modules integrated on the Acquia Commons distributions, where we plug with Organic Groups too, and it's working good! It's has basic features now, but it's evolving fast.

About the Comments support, we are using the Reply module, that even being simple, it's working for the basic question that we need: discuss on the cases. Comment Driven updating on Cases is very far from being available. If someone has any ideas, would be great.

We are really engaged on this Scrum module, so, any feedback will be great.

Niklas.G’s picture

Niklas.G CreditAttribution: Niklas.G commented

Sounds really great,have been looking for a Scrum module that works with open atrium 2 and/or commons. Will it be possible to use your scrum module for kanban without too much work?

johnv’s picture

johnv
Primary language Dutch
CreditAttribution: johnv commented

ATM we're converting the Workflow module to a Workflow Field (using Field API) and preparing it for a D8 version. Perhaps it can be useful as a Status field in CaseTracker. (See this issue)

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

Great! I'm really dissatisfied with the actual solution that i made to the status field and was thinking about working on it asap, but i was thinking of a taxonomy term field or something like the Case Tracker on D6, with different status options per project.

Right now, does Workflow work with any Entity Type or only with this new approach, with a Workflow Field, this will be possible? I only used it with Nodes.

johnv’s picture

johnv
Primary language Dutch
CreditAttribution: johnv commented

@pedro, if you download the -dev version, you'll find a new submodule ''Workflow Field'. Not all other submodules will support it.
ATM it only works with Nodes, and 1 workflow per node.
I've created new tasks:
#2102405: Add Entity support for Workflow Field
#2102409: [META] Support multiple workflow_fields per Node type (Entity bundle).
Feel free to comment on them.

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

The alpha 2 was released yesterday: https://drupal.org/node/2112745

metzlerd’s picture

metzlerd CreditAttribution: metzlerd commented

I have been using casetracker for years (since early 5.x days) , and this entity direction may make me need to stop or fork.

The use of nodes and comments are very important to the ability manage the history of a case and its state transitions. Also using nodes means that you can actively leverage node access control modules to further limit cases. Using nodes means you can close comments on an issue with stock functionality. It also allows use of subscriptions and notification modules out of the box, not to mention views, workflow, etc.

Once you step away from this, you need to reinvent all of these features from scratch? This will set casetracker back for the forseeable future.

Perhaps I misunderstand though... How does making cases and projects not nodes make the system more flexible instead of less?

Organic Groups integration is something I am very interested in.... how does that get achieved when you are talking about entities instead of nodes? How are cases limited to members of the group for example. Do all these things become impossible just because we need to divorce from node/comments?

Do I need to consider forking to get these features?

ahillio’s picture

ahillio CreditAttribution: ahillio commented

Hi! How's it going with this? (as in, is it too late to offer feedback here?) I think 2.x will be much improved and that's exciting.

I don't like how 1.x has its "case states" or how it makes the association between project and case. It seems like I could just configure my own system to manage my projects just with simple fields, taxonomy, entityreference etc... except for the ability to change the task's values by posting a comment. But for that I just found https://drupal.org/project/comment_alter.

In 2.x it seems good to have project be its own type of entity (I could even see a project being a taxonomy term since it groups tasks together) but nodes seem advantageous for tasks - at least as of now. For my use, it's not a task tracking system without comments (seems reply works?) and it's almost as important to be able to change the status in the comment.

Is it too late to consider making tasks/cases be nodes?

With cases as nodes, it can work with Redhen CRM's group feature - giving client's access to their project's tasks - which is what I'm hoping to do.

Thanks for working on this project!

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

I've used Open Atrium on a couple of sites and liked the way it was possible to have a casetracker per group. I just installed v7.2alpha2 and player around with it, but couldn't find any way of adding projects or case tracking queues to a group.

Would be great with an update on how the current plans look. Is it possible to get casetracker to work with OG?

tanius’s picture

tanius CreditAttribution: tanius commented

For a minimum viable workaround (custom Drupal module) that integrates Case Tracker into OG, see my blog post here: "How to integrate Casetracker with Drupal Commons 3?".

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

@tanius, thanks for the link to your blog post.

As I couldn't find "/admin/config/casetracker/settings" I Just would like to confirm that you used the 7.1x branch you where using to integrate with?

adixon’s picture

adixon CreditAttribution: adixon commented

I was just thinking about OG integration and missed the obvious, which is that if you want exactly one project per group, you might as well make your project entities the groups themselves. Needs a little bit of understanding of how OG works, but also demonstrates the niceness of the entity abstraction.

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

In my case I want to mainly use the case tracker. One in each group, but with the possibility to move issues between groups like between projects here on d.o.

While it is possible to do what you suggest, add a group to the project, it is limited to that. The site I am building will have several different types of groups, including for nodes and taxonomy terms.

If, on the other hand, both projects and cases can be added to groups, then anything that can be a groups could then also make use of CaseTracker.

I'm no skilled coder, but would gladly help anyway I can with this and other improvements of this project.

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

Just want to say that I am actually glad I discovered the current limitations. It forced me to rethink the whole approach from new angles. Now I've come up with an idea using Entity Reference that will be even better and way more flexible than I though was possible with the old way.

Just begun testing it out, but if I get it working I'll post about it.

metzlerd’s picture

metzlerd CreditAttribution: metzlerd as a volunteer commented
Status: Active » Closed (won't fix)

After conversing with @pedrorocha, I've taken over the maintenance of this module and have decided to discontinue this branch. I have begun work on a drupal 8.x version that will create case tracking as fields on nodes so that we can preserve the comment functionality of the 7.x-1.x branch. See #2560519: Drupal 8 Case Tracker for more info.