SDM 12.7 - Sorting a list of tickets

[Tammy Zadell]

Hi everyone,

 

I have a question about the behavior when sorting a list of tickets.

 

Here's an example:

 

I search on active incidents assigned to a specific routing group.  When I sort the list by the 'Assigned To' column, it changes the sort to be by the Assignee, with tickets with no assignee at the top, and then the ticket assignees are listed alphabetically by last name.  Within that sorted list, if I look only at the tickets that are assigned to 'Doe, John', the order of those tickets seem to be random (not in open date or ticket # order).  And if I do the same search and sort again immediately after that (no new tickets have come in), the order of those same tickets are now in a different random order.  I don't think there is any way to specify a secondary sort (right?) -- But wouldn't you think that whatever order it is putting them in would be consistent each time that you do the same search/sort?

 

Thanks.

Tammy

 

 

 

[Tammy Zadell]

Anyone have any feedback on this one?

 

I have a question about the behavior when sorting a list of tickets.

 

Here's an example:

 

I search on active incidents assigned to a specific routing group.  When I sort the list by the 'Assigned To' column, it changes the sort to be by the Assignee, with tickets with no assignee at the top, and then the ticket assignees are listed alphabetically by last name.  Within that sorted list, if I look only at the tickets that are assigned to 'Doe, John', the order of those tickets seem to be random (not in open date or ticket # order).  And if I do the same search and sort again immediately after that (no new tickets have come in), the order of those same tickets are now in a different random order.  I don't think there is any way to specify a secondary sort (right?) -- But wouldn't you think that whatever order it is putting them in would be consistent each time that you do the same search/sort?

 

Thanks.

Tammy

[Legacy User]

I would suggest logging a Support Case for this...

[Tammy Zadell]

I will, thanks.  So that's not normal behavior then, huh?

[Legacy User]

Not sure, we'll need to investigate further ;-)

[Michael Mueller]

Hi Tammy.

this is my understanding.

I think it is a common database behaviour that when sorting records trhough a column which has the same value for each record, the order of the records is not predictable and and you can not expect,that you will get the same order again when doing another fetch with the same order criteria.

There are capabilities to specify a secondary order criteria. but not on the fly.these has to be hardcoded in the object definition of SDM.

Kind regards

............Michael

[Tammy Zadell]

Thanks, Brian and Michael.  I certainly hope that you're wrong about that, Michael... Because it makes things very difficult when teams are trying to do a team conference call to review their open tickets, and each of them do the same search and sort, but they aren't seeing the exact same results on the screen to review the tickets.

 

Tammy

[Michael Mueller]

hi Tammy,

I think  I understand your concerns.

But I'm quite sure there is a solution for most of the common scenarios,

In the case you have mentioned what are your common team attributes?

If it is for example the group attribute of your tickets and everyone would search for tickets in his group(s) each one would get the same result in the same order, ordered by the default column( open_date as far as I know).

Now it should be defined if sorting is really needed to go through this list of tickets. if so,which one? As said ,I'm quite sure that it would be possible in this example to define at wo level sorting for the group column,so that the tickets are orded by group snd opend_date additionaly, for all tickets of the same group.

Would that help?

regards

...........Michael

[Tammy Zadell]

Thanks, Michael.  But my example is based on one team and how they want to review their teams list of open incidents or requests with each other over the telephone, by searching on their group's open incidents or requests, and then sorting on the assignee field.  Other teams might want to sort on other columns, so I don't think coding it for one type of sort is going to help much.  Right now I don't really care what it's doing as it's 'secondary sort', but my expectations are just that it should be consistent and do the same thing for both people.

 

Tammy

[Michael Mueller]

Hi Tammy.
That's what I was trying to say, it is a matter of process and knowledge. And because a process can be controlled /defined by an organisation the organisation can try to support these processes. My intention is to offer an idea that the tool is able to support your processes. 
kind regards
......Michael

[Tammy Zadell]

Hi Michael,

Well, maybe I'm misunderstanding something, but I can't really define a process for how all team members will sort their group's open tickets to review them together - to say that you will always sort by the assignee column, and when you do that the secondary sort results will be consistently the same.  Teams need to be able to use the system with flexibility, to search and sort in a way that makes sense to how they work together and collaborate.  If I've misunderstood, and after manually sorting on any column your idea will then make the secondary sort be consistent (and it doesn't require a customization to achieve), then that would be great.

 

Tammy

[Tammy Zadell]

I had submitted a support ticket for this, and the response was that it is "working as intended".... (Sigh)....   I just can't understand how inconsistent results would be something intended, but oh well...

 

Tammy

 

[Michael Mueller]

Hi Tammy.

I understand yoru disappointment. Well at least to me the word intended is somehow misinterpreted. I don't think that someone decided that SDM should return an undefined order when sorting on a column with unique values. My guess is, someone decided to use the database for sorting, because that's what databases are for and can do very efficiantly.

Sure you may ask why SDM does not handle this common DB behaviour out of the box in a senseful way. Maybe this is worth  an idea.

Nevertheless in the case we discussed, I had another idea, why not defining a scondary sort column for all columns displayed in the cr list.(not that many) This would keep the flexibility you were looking for.

Neverthelesss you may think about carefully which secondary columns to use for which primary column. especially for the assignee and group columns.

Kind regards and thanks for the update with the result of the support ticket.

.......Michael

[Tammy Zadell]

Thank you, Michael.  As far as defining a secondary sort goes, I think that since the default sort is on the open date, that would be an appropriate secondary sort for all of the sortable columns.  But how do you define a secondary sort?  Is this done on the list forms?

 

Tammy

[Michael Mueller]

Hi Tammy.

Sorry for that late response. But it took me a bit to figure out the best approach and to do some tests.

So,yes, fortunately you are able to define sort orders in the htmpl instead of the need to define the sort behaviour in the object definition.

Copy your bopcf/www/htmpl/web/analyst/list_in.htmpl file to your site/mods/www/htmpl/web/analyst directory if not already done.

This is the template for the incident list only, if you want to have the same change for the request list and the problem list, you would neeed to do the same thing with the files list_cr.htmpl and list_pr.htmpl.

the displayed columns are defined by the lsCol macros in these files. This pdm_macro knows a "sort" parameter,with which you can define additional sort orders.

For example , I did the following change for the assignee column:

<PDM_MACRO name=lsCol hdr="Assigned To" attr=assignee sort="assignee.last_name ASC, group.last_name ASC, open_date DESC">

So now when I click on the asssignee header the list gets sorted by the last_name of the assignee in an ascending order, and for records with the same asssignee it gets sorted by the group name ascending;  and for records with the same assignee and the same group open_date will be used as the third order criteria.

Don't forget to do a pdm_webcache after changing these files.

These changes make sense only for columns defined as a single column and not for columns which are part of the expandable part of each record.

Hope that helps and kind regards

............Michael

[Tammy Zadell]

Thanks, Michael.  This is excellent!  I will try this when I can (might be a little bit), and will let you know.

 

Thanks.

Tammy

[Tammy Zadell]

Hi Michael,

 

Sorry for the delay on me trying this....

 

I've just added the sort to the list_cr.htmpl form, with the exact syntax that you gave me.

 

This is what my line of code looked like:

<PDM_MACRO name=lsCol hdr="Assigned To" attr=assignee startrow="no" sort="assignee.last_name ASC, group.last_name ASC, open_date DESC">

 

But after publishing the change, when I tried to search requests, it gave me this error:

 

Unable to Connect

AHD4409 pdmweb is unable to connect with the webengine

Please contact your CA Service Desk Manager administrator and verify that the CA Service Desk Manager server is up and the webengine is running.

 

Any ideas?

 

 

Thanks,

Tammy

[Michael Mueller]

Hi Tammy.

Oh that's to bad! When do you get this error?

Directy when you try tro access the web GUI ,or when you do a search for requests?

If you are not even able to access the web GUI , I would say this is not related to the change you've made in list_cr.htmpl, but due to other circumstances.

is the webengine process running at all?(pdm_status)

do you use tomcat or a diiferent webserver like IIS or apache?

Which SDM version are you running in which setup(conventional / AA)?

Whatever the reason is you should find some hints in the logs.

I hope you were able to revert the changes so that you have a running system again.

And sorry for the late response.

Kind Regards

..........Michael

[Michael Mueller]

Hi Tammy.

I should read you post(s) mor carefully!

So I understood,that you get this error when you do a search for requests.

Hmm, As said. there sholud be some hints in the actual stdlog file.

And I recognized that you are running 12.7,which could be  the root cause,already.

I did my tests on 14.1.And maybe this kind of sort definition is not yet supported in 12.7.

Unfortunately,I don't have a 12.7 system available to do some tests.

Kind Regards

...............MIchael

[Tammy Zadell]

Hi Michael,

Yeah, no need to worry.  The error occurred when doing search.requests, and was resolved when I removed the code.  I didn't check the logs at the time, but will try again when I can and see what gets posted there. 

 

Thanks,

Tammy