Subfields in Manage authorities not alphabetized

Bug #781008 reported by Mieke Stroo
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
2.3
Fix Released
Undecided
Unassigned
2.4
Fix Released
Undecided
Unassigned

Bug Description

Evergreen 2.0.3
PostgreSQL 8.4
There are three problems:
1. In manage authorities the subfields are not alphabetized. It is very difficult to find an authority. Examples Opland and NVV. Jongerencontact
2. When browsing using next or previous in manage authority the same authority keeps appearing time and again. Example NVV. Afdeling Zuid-West-Limburg
3. Retrieving an authoriy with a subfield in a bib record using the right-mouse click, the system only searches for the name mentioned in the subfield. Example NVV. Jongerencontact.
See attachment for the examples

Revision history for this message
Mieke Stroo (mst-iisg) wrote :
Revision history for this message
Dan Scott (denials) wrote :

If there are three problems, then three separate bugs should be opened so that we can handle them separately.

For #1, please provide the complete authority records that match the entries around Opland. I would expect "painter", "designer" and "draughtsman" to all be in $e subfields, but it is not apparent from your screenshots that that is the case.

Not sure what to say about #2, but if it turns out that #1 really means that only $a is being alphabetized and the remaining subfields are random, it sounds like it's just a variation on #1.

For #3, the system currently assumes that whatever term you are right-clicking on is the primary term that you want to search for in the $a subfield of the authority record.

Changed in evergreen:
status: New → Incomplete
Revision history for this message
Erhan Tuskan (etu-7) wrote :

We (probably the only user of Evergreen which struggles with authorities) try to describe the problem with sorting of authorities once again in order to make it clearer and to bring it again to the attention of the community. Thanks in advance.

Erhan Tuskan

Problem definition:
Authorities which contain other subfields (e.g. $b, $c, $d, $e, etc.) than subfield $a are not sorted alphabetically. It seems that Evergreen is sorting only one subfield, regardless of how many subfields there are. This is the case both in the interface of Manage Authorities as in the browse list to add authorities during bibliographic cataloguing. The random order makes it difficult to find a specific authority

Requirement:
The group of returned records with the same value in the subfield $a (in our example “Amnesty international”) should be in turn sorted by the second subfields ($b, $e, $d, $c, etc.) and every next subfield

For screenshots of returned results and examples of full authority records see the Word document attached

Revision history for this message
Mike Rylander (mrylander) wrote :

Here's a branch to address this. From the commit:

Preserve record order of subfields for authority heading extraction

When extracting headings from authority records we currently read the
subfields of a tag in configuration order. We should, instead, read
them in record order, to preserve the desired sorting properties that
the cataloger has encoded in the record.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/authority-sf-file-order

tags: added: authority pullrequest
Changed in evergreen:
status: Incomplete → Confirmed
importance: Undecided → Medium
milestone: none → 2.5.0-m2
Yamil (ysuarez)
tags: added: authorities
Revision history for this message
Yamil (ysuarez) wrote :

I just signed off on Mike's branch. Hopefully I did this correctly. Do I or somebody else need to add a "pullrequest" tag to this bug? Just trying to learn.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/ysuarez/authority-sf-file-order

Here are examples of how well the fix worked....

1) Search for subject authorities: Jazz

- without fix
http://www.flickr.com/photos/98246313@N05/9184401009/

- with fix
http://www.flickr.com/photos/98246313@N05/9186620516/

2) Search for subject authorities: Jazz France

- without fix
http://www.flickr.com/photos/98246313@N05/9186620492/

- with fix
http://www.flickr.com/photos/98246313@N05/9184400967/

3) Search for author authorities: Bach

- without fix
http://www.flickr.com/photos/98246313@N05/9184401093/

- with fix
http://www.flickr.com/photos/98246313@N05/9184401065/

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

Yamil,

It already has the pullrequest tag, so no need to add it.

One of the developers will get around to merging the code into master soonish.

Thanks for testing and signing off on the code!

Jason

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

Looks like it needs an upgrade script to me.

Revision history for this message
Yamil (ysuarez) wrote :

Jason,

Oops, I missed that it was listed already. I played with the tags earlier, but I thougt it was on another bug.

Also, Jason thanks for helping me learn how to sign off in while we were in Vancouver.

Yamil

Revision history for this message
Mike Rylander (mrylander) wrote :

Jason,

Ofttimes in the long-ago, especially for simple updates (replacing functions and such), we've left even the creation of the upgrade script to the final committer. I guess that doesn't happen as much these days, though.

I've added an upgrade script to Yamil's signoff branch.

Revision history for this message
Yamil (ysuarez) wrote :

Mike/Jason,

Would it help or is it even needed for me to sign off on Mike's last commit? Just what the general procedure is on Collab branches.

Thanks,
Yamil

Dan Wells (dbw2)
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Dan Wells (dbw2)
Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
status: Confirmed → Fix Committed
Revision history for this message
Dan Wells (dbw2) wrote :

Three cheers for fixing two-year-old bugs! Pushed to master; thanks Mike and Yamil.

Mike, can/should this be backported? If you think so, please add series targets for 2.4/2.3, as appropriate. Thanks again!

Revision history for this message
Gislaine Hamelin (gislaine-hamelin) wrote :

Hi,
 We are experiencing this also at StatCan. I want to ensure that I understand the lingo being used here. We recently migrated to 2.4.1. When Dan says 'pushed to master' what does that mean?

When he says 'please add series targets for 2.4/2.3' does this mean patches will be applied to those versions? This fix would assist us greatly as we have numerous subject headings that have 3 or more subfields. I have attached a screen cap of the filing of Industries with a $z subfield. Canada files at the top, then again later with $b Brazil filing after Canada.

Revision history for this message
Yamil (ysuarez) wrote :

I am not a developer, but I will try to answer some of your questions as best as I can

> When Dan says 'pushed to master' what does that mean?

That means at that code changes that were stored in a particular test/topic Git branch was moved to the Git "master" branch on that day. The Git master branch is used by the EG developers to store the code for future/unreleased versions of EG that sometimes have not been assigned a version number yet.

Since the time that Dan "pushed to master", the master Git branch was split into additional branches to be used for preparing to release EG 2.5. I strongly believe that at this point Mike's fixes will make it to EG 2.5 once it is officially released. His fixes could also be tested out if you install the alpha or beta versions of EG 2.5.

 > When he says 'please add series targets for 2.4/2.3' does this mean patches will be applied to those versions?

Here Mike is asked that if he thinks this fix should be backported to EG 2.4.x, that he should update this bug report to indicate that intention. At this point, this bug report has not been updated to reflect those intentions.

I manually added this fix to my EG 2.4.0 system by grabbing the changes that Mike did, here is the SQL

https://docs.google.com/a/berklee.edu/file/d/0B4URatF-NX5LeXpsbWxLd3Z5R2s/edit

This thread shows the advice I was given to update the dabatse trigger that needs Mike's changes and how to trigger a mass authority ingest so the fix takes hold....

http://georgialibraries.markmail.org/thread/gtnnf4l2ra7c6ozv

Again I am not a developer, so I may have gotten some details wrong,
Yamil

Revision history for this message
Gislaine Hamelin (gislaine-hamelin) wrote : RE: [Bug 781008] Re: Subfields in Manage authorities not alphabetized
Download full text (3.4 KiB)

Thnaks Yamil. This is awesome.

Gislaine Hamelin
Integrated Library Systems Coordinator |Coordonnatrice du système intégrée de la bibliothèque
Information Management Division | Division de la gestion de l'information
R.H. Coats Building | Immeuble R.-H.-Coats / Floor | Étage 2 Q
Statistics Canada | 100 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 100, promenade Tunney's Pasture, Ottawa ON K1A 0T6
<email address hidden>
Telephone | Téléphone 613-951-4576
Facsimile | Télécopieur 613-951-0939
Government of Canada | Gouvernement du Canada

-----Message d'origine-----
De : <email address hidden> [mailto:<email address hidden>] De la part de Yamil
Envoyé : August-28-13 12:30 PM
À : <email address hidden>
Objet : [Bug 781008] Re: Subfields in Manage authorities not alphabetized

I am not a developer, but I will try to answer some of your questions as best as I can

> When Dan says 'pushed to master' what does that mean?

That means at that code changes that were stored in a particular test/topic Git branch was moved to the Git "master" branch on that day.
The Git master branch is used by the EG developers to store the code for future/unreleased versions of EG that sometimes have not been assigned a version number yet.

Since the time that Dan "pushed to master", the master Git branch was split into additional branches to be used for preparing to release EG 2.5. I strongly believe that at this point Mike's fixes will make it to EG 2.5 once it is officially released. His fixes could also be tested out if you install the alpha or beta versions of EG 2.5.

 > When he says 'please add series targets for 2.4/2.3' does this mean patches will be applied to those versions?

Here Mike is asked that if he thinks this fix should be backported to EG 2.4.x, that he should update this bug report to indicate that intention.
At this point, this bug report has not been updated to reflect those intentions.

I manually added this fix to my EG 2.4.0 system by grabbing the changes that Mike did, here is the SQL

https://docs.google.com/a/berklee.edu/file/d/0B4URatF-
NX5LeXpsbWxLd3Z5R2s/edit

This thread shows the advice I was given to update the dabatse trigger that needs Mike's changes and how to trigger a mass authority ingest so the fix takes hold....

http://georgialibraries.markmail.org/thread/gtnnf4l2ra7c6ozv

Again I am not a developer, so I may have gotten some details wrong, Yamil

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/781008

Title:
  Subfields in Manage authorities not alphabetized

Status in Evergreen - Open ILS:
  Fix Committed

Bug description:
  Evergreen 2.0.3
  PostgreSQL 8.4
  There are three problems:
  1. In manage authorities the subfields are not alphabetized. It is very difficult to find an authority. Examples Opland and NVV. Jongerencontact
  2. When browsing using next or previous in manage authority the same authority keeps appearing time and again. Example NVV. Afdeling Zuid-West-Limburg
  3. Retrieving an authoriy with a subfield in a bib record using the right-mouse...

Read more...

Ben Shum (bshum)
Changed in evergreen:
status: Fix Committed → Fix Released
Revision history for this message
Mike Rylander (mrylander) wrote :

I've added targeting for 2.3 and 2.4. The backport is simply adding 0802 as a new number to 2.3 and 2.4. We should put placeholders with that new number in master and 2.5, as well. Anyone want to comment on this before I move forward?

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

I've got no issues with this plan. Fire away!

Revision history for this message
Mike Rylander (mrylander) wrote :

Done and done. I ended up just reapplying 0802 from master through 2.3 as 0848. As noted in IRC, there's no reason not to, and it's simpler in the end.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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