Drupal 6 Compatibility

Are there any plans to release this for Drupal 6.x?

Case Tracker has views integration, views is not ready for drupal 6.

I'm planning to create a 6 version AFTER views2 is released (waiting for the views2 api).

Views has progressed a great deal since the last post and has a solid api. So I thought I'd ask about the status and plans for the D6 port?

Setting issue as active due to the availability of views 6.x

subscribing..

Any update? Just waiting on this module to upgrade to D6.

subscribing...

subscribing

subscribing

subscribing (and hoping!!)

You might want to just skip D6 and move on to D7.

subscribing

One more subscription

and another subscription

subscribing

So, has anyone given up and converted to something else? Are there any other viable options out there?

subscribing...

I have given up. It's not compatible with D6 and doesn't look like it is going to be any time soon, and D7 is already on the horizon so even if it meets D6, who knows about the future? I don't have a huge amount of data in my CT system and I'd hate to think of the impact of the slow evolution on someone who has a lot of data.

Casetracker has been abandoned in my usage and I am 90% finished with replicating the function I needed it for, using simply CCK and Views. And I am far from a programmer. I will be happy to export my Views and give you info about my new Content Type "Probationer." I found CCK quite easy to use and setting up the Views is really simple.

My end result is a flat-file database in essence with a record for each Probationer with data such as:
County
Cause #
Background narrative
Date into Drug Court
Date out of Drug Court
Status in the many phases (radio buttons)
Factors about their addiction (radio buttons, check all that apply)
Type of probation (buttons again) - deferred, regular, pretrial
Risk level (1-5)
Assigned judge

Think of it as Project Management, each probationer being a project.

gil

Capnj,
I did not used the case tracker (drupal 5), but heard it was useful to build project->task(s) type situations.
For your Probationer type how did you build the "followups" to each ProbationerCase(Cause#). If you have time would not mind looking at your views export. TIA -SA

Please, drupal 6!

hoping

+1

I'm looking at porting it to D6 - has anybody else started already? If I'll be able to do it (time-wise) i'll share with the rest.

subscribing

Capnj, would you be so kind as to share your view? It might be a good place to start in the interim. Can you also share your node type?

Thanks!
Chris

Amitaibu, Id be interested in splitting the work..

Hi all,

Attached is a patch that adds Drupal 6 support to casetracker. We (developmentseed) use casetracker a lot and have been running this version for quite some time - it's been very stable and useful for us. Hopefully we can use the patch as a way to move forward.

Jeff

While working on the same port, at a certain stage I had a few thoughts that I started to implement, and I think are worth discussing.

In D6 Casetracker can harness the power of CCK resulting with lots of benefits (e.g. each user can define the CCK fields for the cases; Views intergation, etc').

Here's the idea I came up with:
* Make the module dependent on CCK and Diff module (we'll talk about Diff later).
* Allow user to define which content type is a case type. We don't need to define a project - it would be up to the user to create a node reference to a project (if she so desires). And also define which fields in that content type can beused for casetracker.
* In the comment form, form_alter() it and add the CCK fields that are 'casetracker fields'. (snap1)
* Instead of letting casetracker track all the changes, we can rely on the node revisions. Casetracker only needs to holds the comment ID, node ID, and revision ID. So, when we want to show that the case state changed we can use diff module to show the difference of the revisions (snap2 - User changed the title and assigned it to another user).

My biggest concern so far with this approach is the node_load() of the diffs; However maybe the advantage of using other modules to do all the heavy lifiting + the benefits of CCK worth that.
Also in D7, fields are in Core and maybe Diff will someday be as well (#120955: Integrate Diff into Core).

What do you guys think?

I had this thought as well when upgrading (I'm partially responsible for the d6 upgrade patch above) but realized that there are downsides to a CCK-based approach:

• Using revisions per comment to track case state changes seems logical at first but has the downside of growing an already large table. Node revisions is often one of the largest tables in drupal installs and it seemed dangerous to grow this table with every comment.
• We've added Views 2 integration for the existing casetracker fields already.
• Eventually you will want smarter handling of casetracker fields than generic CCK fields will provide. For example, a textfield with options sounds great for case statuses at first, but will fail to provide what you need when you want to treat closed, open, deferrred, etc. states as more than strings. While casetracker isn't great at this currently, using an ID is more stable than an arbitrary user-defined string. We're hoping to add additional semantic/meaning to states in the future and switching to CCK fields would be a setback here.
• The upgrade path from the existing casetracker infrastructure to a CCK/node-revision based storage would be frightening. You can imagine the difficulty of doctoring the node revisions table for nodes that have had case states changed in both comments and revisions.

...Node revisions is often one of the largest tables in drupal installs and it seemed dangerous to grow this table with every comment.

Well, not every comment - just when changing one of the CCK fields, but yeah - that's a valid concern.

...but will fail to provide what you need when you want to treat closed, open, deferrred, etc.

If we use CCK fields then we can use the existing Rules integration of CCK and act upon those fields. Plus we remain with the fact that either the fields are hardcoded (and Views 2 integration needs to be written specifically).

The upgrade path from the existing casetracker infrastructure...

I fully agree - an upgrade path is simply not realistic. However, if the CCK approach is found to be the right/ agreed one then it will have to be without an upgrade path.

About #26, Against which version did you patch it - I wasn't able to apply it? Maybe you can gzip it...

Here's my patch - still might be rough on the edges ;)

Dependencies:
* CCK (fields in core in D7).
* Elements (tableselect in D7).
* Diff (might be in D7).

Note: you will need to patch Diff module #365140: Allow other modules to alter $node_diffs.

I've updated the README.txt to reflect the changes of this patch.

Sorry if the patch in #26 doesn't apply. We're maintaining it in svn here https://svn3.cvsdude.com/devseed/sandbox/drupal-6/casetracker/ that should just run.

Thanks for the SVN link.
Here's once more the CCK casetracker, only with less cruft.

Very cool I look forward to checking these out. Just to let you guys know
I posted about casetracker being abandoned to see if we can get access to the project and theyre talking about depreciating it:

http://drupal.org/node/302491

Hey all,

I've been given maintainership of casetracker and getting working Drupal 6 code out is the first priority.

Jeff

@Jeff,
I think that we need to understand which of the solutions proposed is better for the community. Maybe if people will try them both, and try to implement there use cases with them - we'll be able to get some feedback.

Agreed, and I think that whatever we do is going to be some combination of a few people's upgrades. My plan here is to get some Drupal 6 code in the repository so that we can have constructive conversations about specific differences.

However. I do disagree with one point you made above - and upgrade path is very important to this module. More the a couple companies business process history capture using this tool and we don't want to drive them else where just because we're not creative enough to come up with a reasonable upgrade path.

That being said I'm all for your approach of using accepted tools, like cck, to replace what had been build in functionality. Casetracker was built before a few module we take for granted now, like cck and views, were as flexible are they are in Drupal 6. We have some refactoring debt to deal with:)

Just to let you know casetracker_admin.inc is not uploaded to "/contributions/modules/casetracker".

Thanks for the svn link, that where I found it.

@jmiccolis,
We can make an upgrade path for the CCKase tracker - catchy name ;) - it will only need some pre-requisites, like having the same CCK fields that can be mapped to the Casetracker fields. It needs some work, but sounds possible.

@leevester, thanks for the heads up, it's in there now.

@amitaibu, If cck ends up being the answer I think some assumptions about the upgrade patch is certainly ok.

I've split the CCKase trcker issue to another thread #372124: CCKase tracker, D6 port suggestion

Subscribing.
Sorry for the duplicate post.

Hi All,

I've branched for D6 and a dev tarball is now available - We're getting closer! Most of the casetracker functionality is present in the dev tarball, with the notable exception of casetracker_mail - which has it's own ticket http://drupal.org/node/378072

As is also noted above, the very interesting "CCKasetracker patch" has an ongoing discussion here http://drupal.org/node/372124 and will probably be part of a later D6 or D7 release of casetracker.

I'm setting this ticket to 'fixed' and I welcome people to open individual tickets for any issues that are found with the 6.x-1.x-dev code.

Please note Drupal 6 code is a substantial rewrite which some large changes, for example the built in query builder has been dropped in favor of using the Views module, but upgrades from D5 should be pretty painless.

Cheers!

many thanks!