Customization of fields

+1 for the generic fileds. While the terminology that is displayed to the user can be changed in module, doing so takes some time, and then all that hacking has to be done over and over with each update to the module. If the terminology itself could be user defined that would really extend the usefulness of Case Tracker. For example, I hacked the module some time ago and changed "Project" to "Agency", "Case" to "Agency Case No." and "Assigned to" to "Prosecutor Assigned" to name a few. It took a while to find all the places where these terms are located in the module, but it didn't seem to bad at the time. However, along with the next module update, came the chore of changing all the terms that I'd changed before. Making the ability to change at least the main lables part of the module itself would be fantastic.

Roger

KSA213755 : you can try using locale.module, create a "custom_english" language and translate the terms you don't like.
RyanR was thinking about "adding" fields to cases.
For projects, you can design a cck node type and associate it with the casetracker via the settings page.

I'm not familiar with the locale.module, but I'll try that out and see how it works out. Thank you.

+1 for the ability to customize the types and statuses in-module as well. This would be possible with localization if the module followed best-practice and used the t() function for the various status a case can have, but it doesn't at the moment.

It should use t() and it would ALSO be good to have the list of types and case stati be customizable. This would allow people to add/rename these to create the workflow that works for them. It can be accomplished pretty easily by having a couple of arrays stored in via variable_set().

In fact, these are already being stored in the DB in their own table. All that's needed is to open up an admin interface to manipulate these. States could be added/removed pretty easily if code like this:

   $classes = array($status_id_arr[0] => 'opened',$status_id_arr[1]=>'closed',$status_id_arr[2]=>'resolvedstaging',$status_id_arr[3]=>'resolvedproduction',$status_id_arr[4]=>'tested_staging',$status_id_arr[5]=>'resolved');

Were made slightly smarter. Keys can be generated on the fly from the data in the casetracker_case_states table.

This would add quite a lot of extensibility to this module.

Ok, here's a patch.

This does a few things. First of all, it amends the cases_table functions to work off the database, rather than assuming there are always six states and that they are all the same. This was already a little broken. It also removes some depricated code.

I also added a hook_help case for the admin/setings/casetracker page that points admins at admin/case for the states. That page now defaults to the overview rather than a page with three links to that page. On that status-state overview page I also removed the ID column (which is meaningless to the admin) and had the query sort by case_state_realm rather than ID, so types of states stick together.

Thre we go...

Thanks Josh! Can't wait to give the changes a try as soon as I get a chance. This module is at a stage where it really needs people to pick the ball and effectuate changes, so your work is welcomed.

I changed the title back to something more descriptive.

Hi Josh:

Your patch applied for me.

* I do see admin/case/states.
* admin/case still defaults to the page with the 3 links on it.
* Perhaps "Administer case fields" menu item can be moved to settings > case tracker > case states (and thus remove the unnecessary "administer > case" item.

Thanks!

I'm closing - this was rewritten and, with CCK ability hitting HEAD today (though still in a working/draft state), customizing the existing case states, or adding more via CCK, is possible.