It you create a view where you can sort on Case ID you will discover that this does not work. The sort only takes the cas part of the ID into account, not the project part.

Comments

Gerhard Killesreiter’s picture

Same applies to the case priority, case status, case type, assigned to, and project title field. In all cases the sorting works by sorting on the underlying numerical ID. We want the sorting to work on the alphanumerical label.

zero2one’s picture

Status: Active » Closed (fixed)
bradezone’s picture

Title: sorting on case ID does not work correctly » sorting on case ID or priority does not work correctly
Priority: Normal » Critical
Status: Closed (fixed) » Active

this is especially a problem when adding a new priority that you want sorted higher than "high".
It's weird too because when you add a new "case state" it clearly asks for the "weight" but that seems to be totally ignored when sorting in the View.
This is a high priority bug IMO.

mcrittenden’s picture

Title: sorting on case ID or priority does not work correctly » Sorting on any case states or properties not work correctly

Yep, looks like casetracker isn't telling Views anything about how to sort, so Views is just sorting by the property's ID.

Seems like it'd be relatively simple to extend views_handler_sort, perhaps in each of the includes/casetracker_views_handler_field_XXX.inc files to tell Views to sort by weight.

xjm’s picture

Tracking. This is a rather vexing bug.

Boobaa’s picture

Version: master » 6.x-1.0-beta8

Subscribing.

When one sorts on case priority, SQL ends with "ORDER BY casetracker_case_case_priority_id DESC" which is clearly not that she wants. Studying the whole SQL reveals that the needed table is not even JOINed to the query.

Boobaa’s picture

Status: Active » Needs work
FileSize
7.38 KB

OK, let's get my hands dirty by being knee-deep into views2 handler stuff and so.

Assigned is a patch against -beta8 which introduces three new fields: {priority,status,type}_weight. They show the appropriate values and they are sorted by their weight, both normal and click sorting. That's all so far.

I think the best approach would be to merge this functionality back to the original fields (doesn't seem to be a big show, by now). The assignee and project name looks even more easier than this, since they don't have a weight, so they can be sorted by their displayed values. (OK, somebody could say project name sort could take {node}.sticky into account - think weight.module).

Boobaa’s picture

FileSize
10.2 KB

More work done, more changes, more working code. :)

- Original fields are thrown out: they don't JOIN the needed tables, thus Views can sort only by the numerical IDs.
- All the three state fields (priority, status, type) have now a working implementation:
-- they are displayed properly,
-- they are sorted by their weight (both when normal and click sorting is being used),
-- they have proper argument handlers,
-- they have properly working filters.

All of these are tested, but only "by hand": my sample data set was one of our casetracker instances, automated tests are lacking. Default views shipped by the module have not been tested so far.

Three ways to continue:
1. Add back the original fields (most likely the default views depend on them), preferably with the old behaviour (which is wrong, but anyway).
2. Remove support for sorting by the "state" names: this is misleading, as it adds only support for normal sorting by case status (as displayed), but does not add support for click sorting, argument and filter handling, nor anything else.
2b. Add support for sorting by other case state names: priority and type; to be consistent with the previously described behaviour, without support for click sorting, argument and filter handling, nor anything else.
3. Add proper sorting support for the remaining two fields (project name and assignee). Most likely this is something similarly difficult as the work done so far, but looks like I'm getting to understand how Views needs the data to handle these properly.

The fourth way would be to add proper automated test cases for all of the above-mentioned cases, but this is far beyond the scope of this issue and my available time.

Boobaa’s picture

FileSize
13.28 KB

Support for proper sorting on a new project name field has been added.

Boobaa’s picture

Status: Needs work » Needs review
FileSize
16.14 KB

Support for proper sorting on a new assignee name field has been added. Now all the requested fields have counterparts that have proper sorting - for the price that some fields have been removed (see #8).

Setting this to needs review since I don't really know how to continue. There is some unsolved stuff here yet:
1. Should I/we add back the original fields that lack proper sort support, to have existing views working as expected?
2. Should I/we provide an upgrade path that corrects the affected views? (Anyway, is this even possible?)

cYu’s picture

I need this functionality, and this patch gets me part of the way there. I'm using Open Atrium, and I think an issue I'm having is that OA tries to override some of these handlers and now they've changed.

Not familiar with the code, but is it possible to keep the same field/handler names but swap in new behavior? Probably not possible, but if it were it might get around the issue of needing to upgrade existing views or add back old fields to prevent breakage in addition to maintaining current overrides.

Boobaa’s picture

@cYu: Well, there are two (or three) different answers/approaches to this question.

1. Yes, most likely this is possible, and we would cause the least wounds by following this direction. (I was even thinking about coding this, but there are many tasks on my TODO with higher priorities, you know.)

2. Case Tracker itself is still beta, so changes like this are acceptable, since nothing of your data is lost, all you have to change are your views. (Anyway, I'm nowhere to an "official" CT hacker, but I was getting answers like this while chatting with real ones.)

3. Smooth upgrades between versions is not about retaining user interface or functionality, but retaining your precious data. Your data is not even touched by this patch, only the functionality being used to display it on your user interface.

In either way, the views shipped by Case Tracker itself should be updated along with this patch: IIRC there are even CT-shipped views that stop working after applying this patch. After all, I was thinking about kicking it back to "needs work", anyway...

asciikewl’s picture

I tried this patch on OpenAtrium and had to revert because:

1) It broke all the existing views using priority and status. Would it not be a better idea instead of changing the current filters, to add new ones based on the weight of the priorities and states and not the csid.
We have MANY custom views based on casetracked and breaking all of them is not an option. It would also help if the naming stayed the same.

2) The priorities were being sorted alphabetically, which isn't useful either. "Low" is alphabetically before "Show Stopper". Sorting by their weight would be a much better solution.