Summary: | Improve sequence of subfields used and unused while cataloguing | ||
---|---|---|---|
Product: | Koha | Reporter: | Nicole C. Engard <nengard> |
Component: | Cataloging | Assignee: | Galen Charlton <gmcharlt> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P5 - low | CC: | jonathan.druart, m.de.rooy, marjorie.barry-vila |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: | Bug 9472: Order subfields alphabeticaly when cataloging |
Description
Nicole C. Engard
2013-01-23 20:42:20 UTC
Created attachment 37569 [details] [review] Bug 9472: Order subfields alphabeticaly when cataloging On cataloging a record, the subfields without data were put at the end of the other subfields. This patch orders the subfields alphabeticaly even if they don't containt any data. Test plan: 1/ Edit a record with some subfields without any data => The subfield should not be visible (maybe they are if they are mandatory). 2/ Click on a tag to expand the subfield list. 3/ The subfields should be ordered alphabaticaly I have only glanced at your solution, but if this is a general sort of all subfields, it is not the right solution. (In reply to M. de Rooy from comment #2) > I have only glanced at your solution, but if this is a general sort of all > subfields, it is not the right solution. Sort of all subfields for a tag, and not for all tags. What is the right solution if this is not the one? (In reply to Jonathan Druart from comment #3) > Sort of all subfields for a tag, and not for all tags. > What is the right solution if this is not the one? Good question :) I am not aware of UNIMARC specifics here, but in MARC21 there are quite some fields with constructions like this: 100a - 100q - 100d The order should not be alphabetical by default and for all tags. (In reply to M. de Rooy from comment #4) > (In reply to Jonathan Druart from comment #3) > > Sort of all subfields for a tag, and not for all tags. > > What is the right solution if this is not the one? > > Good question :) > I am not aware of UNIMARC specifics here, but in MARC21 there are quite some > fields with constructions like this: > 100a - 100q - 100d > The order should not be alphabetical by default and for all tags. Yes, I am aware of that. But actually, against master, the display is: all subfields, alphabetically sorted, present in the record followed by: all subfields, alphabetically sorted, non present in the record. (search for foreach my $subfield ( sort( keys %{ $tagslib->{$tag} } ) ) ~ l.600-700) This patch just suggests to display all subfields, alphabetically sorted. Which makes more sense. If my dsecription of how it works on master is wrong, my patch is certainly wrong. (In reply to Jonathan Druart from comment #5) > Yes, I am aware of that. > But actually, against master, the display is: > all subfields, alphabetically sorted, present in the record > followed by: > all subfields, alphabetically sorted, non present in the record. > > (search for foreach my $subfield ( sort( keys %{ $tagslib->{$tag} } ) ) ~ > l.600-700) > > This patch just suggests to display all subfields, alphabetically sorted. > Which makes more sense. > > If my dsecription of how it works on master is wrong, my patch is certainly > wrong. Yes, I am still afraid that your patch is actually "wrong" ;) I am not sure if you understood my point too. Hope the following clarifies: I tested this: I had a tag 100 with a 9 4 q d e (4 and e were empty) Without your patch, I look in catalogue marc detail, I see: 100 a q d. Fine! Without your patch, I look in opac marc detail, I see: 100 a 9 q d. Fine too. Now with your patch, I edit the record: The order is now: 4-9-a-d-e-q Catalogue marc detail gives: a-d-q CHANGED ! Opac marc detail: 9-a-d-q CHANGED AGAIN ! Failed QA (In reply to M. de Rooy from comment #6) Ok so the fields should not sorted alphabetically. In this case, the naive approach cannot work, a much more complicated patch must be provided. Reset assignee to default. (In reply to Jonathan Druart from comment #8) > Reset assignee to default. Should your patch be obsoleted too? (In reply to M. de Rooy from comment #9) > (In reply to Jonathan Druart from comment #8) > > Reset assignee to default. > > Should your patch be obsoleted too? Yes, done. |