Ascending order - Click to sort in descending order
Hide
sushant Sushant Paste added a comment -

Tested in r23785.

Show
sushant Sushant Paste added a comment - Tested in r23785.
Hide
demeritcowboy Dave D added a comment -

This doesn't appear fixed. It looks like the system was changed so that no activities record the time component, but that's backwards I think from what the fix should be. All the activities should record the time component.

For example, I just tested a followup activity and it is still appearing as if it came before Open Case. See screenshot.

Show
demeritcowboy Dave D added a comment - This doesn't appear fixed. It looks like the system was changed so that no activities record the time component, but that's backwards I think from what the fix should be. All the activities should record the time component. For example, I just tested a followup activity and it is still appearing as if it came before Open Case. See screenshot.
Hide
demeritcowboy Dave D added a comment -

Sorry by time component I meant the seconds component of the time component.

Show
demeritcowboy Dave D added a comment - Sorry by time component I meant the seconds component of the time component.
Hide
yashodha Yashodha Chaku added a comment -

assigning for 3.1 verification

Show
yashodha Yashodha Chaku added a comment - assigning for 3.1 verification
Hide
shot Piotr Szotkowski added a comment -

Reassigning as per issue verification barter.

Show
shot Piotr Szotkowski added a comment - Reassigning as per issue verification barter.
Hide
dgg David Greenberg added a comment -

At this point editable activities are stored WITHOUT seconds - which I think makes sense since we don't support editing of seconds (and hence the value would be lost / not set in any case). If you find an expected workflow where the current code logic causes mis-sorting, please reopen.

Show
dgg David Greenberg added a comment - At this point editable activities are stored WITHOUT seconds - which I think makes sense since we don't support editing of seconds (and hence the value would be lost / not set in any case). If you find an expected workflow where the current code logic causes mis-sorting, please reopen.
Hide
demeritcowboy Dave D added a comment -

Still able to get mismatched sorting. Suggest ordering by activity.id as third sort parameter as substitute for creation date.

Show
demeritcowboy Dave D added a comment - Still able to get mismatched sorting. Suggest ordering by activity.id as third sort parameter as substitute for creation date.
Hide
demeritcowboy Dave D added a comment -

r25689
Since there are activities with time components this doesn't work by itself so altered the query to actually return 00 for the seconds. Need to return something for the seconds because otherwise overdue hiliting doesn't work.
If there is code elsewhere that calls CRM_Case_BAO_Case::getCaseActivity() and expects there to be non-zero seconds it may cause a problem.

Show
demeritcowboy Dave D added a comment - r25689 Since there are activities with time components this doesn't work by itself so altered the query to actually return 00 for the seconds. Need to return something for the seconds because otherwise overdue hiliting doesn't work. If there is code elsewhere that calls CRM_Case_BAO_Case::getCaseActivity() and expects there to be non-zero seconds it may cause a problem.
Hide
dgg David Greenberg added a comment -

Dave D has tested this after his last query fix and it seems like things are ok now. I checked other uses of CRM_Case_BAO_Case::getCaseActivity and they don't 'care' about the seconds.

Show
dgg David Greenberg added a comment - Dave D has tested this after his last query fix and it seems like things are ok now. I checked other uses of CRM_Case_BAO_Case::getCaseActivity and they don't 'care' about the seconds.