webclient: add volume - parts order

Bug #1760893 reported by Jeanette Lundgren
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned
3.0
Won't Fix
Undecided
Unassigned
3.1
Fix Released
Undecided
Unassigned
3.2
Fix Released
Undecided
Unassigned

Bug Description

Evergreen 3.0.6

When adding a volume to an item with a lot of parts, the parts dropdown lists parts in a seemingly random order. The most recent parts are at the bottom.

The XUL client lists parts in chronological order. See attached image

In add volume, the web client should have an ordered sort for parts.

It would be great if the part drop down defaulted to a reverse chronological sort (most recent first).

Revision history for this message
Jeanette Lundgren (jlundgren) wrote :
Revision history for this message
Jeanette Lundgren (jlundgren) wrote :

Sorry! CW MARS has custom code to do the chronological sort. Default Evergreen sort is alphabetical.

Updated bug: the add volume - parts drop down should follow the default alpha sort.

Revision history for this message
Dan Pearl (dpearl) wrote :

The XUL client at C/W MARS has been customized to list parts in reverse label_sortkey order. For dates, this means the most recent will be at the top of the list.

Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
Revision history for this message
Dan Pearl (dpearl) wrote :
tags: added: pullrequest
Changed in evergreen:
assignee: Dan Pearl (dpearl) → nobody
Revision history for this message
Jason Stephenson (jstephenson) wrote :

Setting this bug to Invalid because it concerns a local customization at CW MARS.

Changed in evergreen:
status: New → Invalid
Revision history for this message
Kathy Lussier (klussier) wrote :

Jason, I still think there is a bug here since the part selector isn't following the default alpha order.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Kathy, you can always change the status if you think I got it wrong. I just want people to know that Dan's code is how we want it sorted at CW MARS and is not written for the community.

tags: removed: pullrequest
Revision history for this message
Dan Wells (dbw2) wrote :

I think we do need *some* sort here, and Dan's fix seems like a good option. Perhaps the biggest question is whether it sorts forward or in reverse, with notable benefits either way.

Dan Wells (dbw2)
Changed in evergreen:
status: Invalid → Confirmed
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.1.1
Changed in evergreen:
milestone: 3.1.1 → 3.1.2
Changed in evergreen:
milestone: 3.1.2 → 3.1.3
Changed in evergreen:
milestone: 3.1.3 → 3.1.4
Revision history for this message
Kathy Lussier (klussier) wrote :

Dan's fix work, but Dan W. raises a good question. I expected the sort to be in ascending order, which is how it was done in the xul client. But the fix sorts the parts in descending order. What do others think? It should be easy enough to tweak to sort descending if we want to replicate the previous behavior from the xul client.

Revision history for this message
Garry Collum (gcollum) wrote :

When adding parts to a volume, I think descending would be better. We use parts for both multi-disc dvd/cd sets and periodicals. Although we have a lot more discs than periodicals, the periodicals have far longer parts lists.

However, if we ever have this conversation pertaining to placing holds in the opac, it would be difficult to explain to patrons why 'Season 8, Disc 5' appears at the top of the list when placing a hold.

Revision history for this message
Dan Wells (dbw2) wrote :

I didn't register a vote before, but I prefer the reverse sort as well. It is initially unexpected, but pays dividends in the long run, which (IMO) ultimately matters more. People are very likely to add things in order, and it's very convenient for the one most recently added to be at the top of the selector.

Changed in evergreen:
milestone: 3.1.4 → 3.1.5
Changed in evergreen:
milestone: 3.1.5 → 3.1.6
Changed in evergreen:
milestone: 3.1.6 → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Changed in evergreen:
status: Confirmed → New
milestone: 3.2.3 → 3.3-beta1
Dan Wells (dbw2)
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
Changed in evergreen:
milestone: 3.3.1 → 3.3.2
Revision history for this message
Dan Wells (dbw2) wrote :

Based on mutual assent of those weighing in, I have pushed this in as offered by Dan P. Thanks, Dan!

Pushed to master through rel_3_1.

Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
status: New → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.