c42668a...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Clean up marc_export and teach it how to export (all) authority records
The new "--type" parameter enables users to specify "authority"
and have the expected result.
Add an "--all" option to marc_export and silence some warnings
Rather than forcing users to generate a set of record IDs using a
separate process, the --all option enables to to export all records
of the specified type. Note that the approach is basic: grab the
record with the highest ID, then start at ID 0 and count up by 1
while trying to retrieve each record along the way. While this will
undoubtedly generate plenty of warnings for deleted records or gaps
in the ID sequences, the alternative of retrieving an ID list for
potentially millions of records in large Evergreen instances wasn't
appealing.
Some other refactoring and fixes:
Three large chunks of code were factored out into subroutines to
make it a little easier to read the main flow of the code.
As we explicitly call uc() on the $format input parameter
to begin with, we don't have to call it subsequently.
If a requested ID did not exist in the database, then
the script would die; now we trap and flag that error but
continue to fulfill subsequent requests.
The --money parameter is now documented in the help, and
the help has a brief overview that describes (poorly) the
expected format for the list of IDs.
An uninitialized variable error when exporting BRE format
records was squashed.
Also, $count{did} and $count{bib} resulted in uninitialized variable
warnings if no records were actually exported, so initialize them to 0.
b0efbc5...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Internationalize the JavaScript portion of the "Manage Authorities" interface
We can use the dojo i18n infrastructure to support translations of the
"Manage Authorities" interface, but unfortunately we still don't have
a TT2 solution for i18n. Still, better to do what we can.
4ec921e...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Improve see from / see also handling in MARC editor authority menu
(Backporting r19091 and r19092 from trunk)
The 2.0-style authorities use a browse menu that currently consists
of matches against the 1XX entries, which makes working with see from /
see also entries rather difficult. To prepare for an authority browse
method that does surface matches against 4xx and 5xx entries, we will
now display the 4xx and 5xx entries for a given authority record
immediately below the 1xx entry in the browse menu, with the entry
text italicized, aligned to the right, and prefixed with "See also" or
"See from" appropriately. This won't provide a perfect alphabetized
solution - we won't know which field provided the alphabetical browse
match, so the best we can do is present the 1xx in the main browse
menu and the 4xx / 5xx below - but it will provide access to the other
references.
We now display the 4xx fields in the authority summary / selector menu
along with the 5xx fields. As part of making the 4xx and 5xx fields
first-class entries in the context menu, 5xx subfields are no longer
appended to their 1xx field menu entry with a "/" in the context menu.
$0 subfields are no longer added to the 4xx and 5xx fields from the
authority summary / selector menu; if a user had selected a 5xx and the
$0 that had been added by the menu, the field would have incorrectly been
linked to the 1xx authority record. To link to a 5xx entry, for now the
workaround is for the user to select the 5xx subfield(s), "Apply Selected",
then right-click on the new subfield to generate a new authority context menu.
To improve the 5xx handling, we need to make the "See also" entry fire a new
authority context menu based on the 5xx contents so that the actual 1xx
authority record can be inserted and linked against.
Consider an authority record containing the following fields:
150 $a Infants
450 $a Babies
550 $a Children
The ASCII-ized authority context menu will now display:
Infants ->
See from: Babies ->
See also: Children ->
The submenu in each case will currently lead to the authority record
for "Infants". If we teach the underlying authority browse and startswith
methods to return matches based on 4xx and 5xx fields instead of just 1xx
fields, then the menu triggered by a right-click on "Childs" might look
like:
Chickens ->
Infants ->
See from: Babies ->
See also: Children ->
Choking ->
The main entry will be out of alphabetical order, which is not ideal,
but the linkage from the 5xx should at least be evident. (Also, this
suggests that when clicking on a 5xx entry in the authority menu is
changed to launch a new authority menu, it should use the 1xx-only
browse variant to avoid showing the record from which the user was
referred...)
e730503...
by
erickson <erickson@dcc99617-32d9-48b4-a31d-7c20da2025e4>
cleaned up vestigal item import API call; repaired some faulty assumptions in vandelay UI regarding which types of import to attempt based on user input
Signed-off-by: Bill Erickson <email address hidden>
