When using the authority finder plugin from within Koha's
Authorities module, you can pick an entry from the 'Special
relationship:' dropdown menu in order to set the relationship
between authorities.
The problem is that in UNIMARC setups, when you click on
'Choose' to select an authority, it does not populate
subfields $3 (Authority Record Number) and $5 (Tracing
Control), which are required for authority linking and
authority hierarchies to work properly.
In MARC21, all authority data is correctly copied over.
This is due to hardcoded subfield values which are
MARC21-specific in blinddetail-biblio-search{.pl,.tt}.
This patch fixes that by checking the value of the
'marcflavour' syspref, and then setting the correct
subfields to copy the authority data to.
Test plan (involves testing in both a MARC21 and a UNIMARC instance):
0) [PREREQUISITES in order for the authority finder plugin to come up
when testing in a UNIMARC instance]
a) You must have at least one authority type besides the 'Default'.
b) View the MARC structure of the 'Default' auth type, then click
on 'Actions->Subfields' for tag 500; click on 'Edit subfields'.
Select the subfield 'a' tab, then pick an auth type from the
'Thesaurus:' dropdown menu; click 'Save changes' at the top.
1) In the Staff client, go to Authorities, then click 'New Authority'
and pick the 'Default' authority type.
2) When the authority editor comes up, go to tag 500 and expand it.
3) Click on the Tag editor icon next to subfield $a.
4) When the authority finder comes up, search for an authority, pick
a relator code from the 'Special relationship:' dropdown, and then
click on the 'Choose' button for one of the authorities you found.
5) In MARC21: all subfields are populated correctly.
In UNIMARC: notice how subfields $3 and $5 are *not* populated.
6) Apply the patch.
7) Repeat steps 3) and 4) above.
In MARC21: all subfields are populated correctly, as before.
In UNIMARC: both the relator code and the authority id are copied
over along with any other subfields that may exist.
8) To ensure that authority linking in the Cataloging module works
as before, launch the bibliographic record editor, find a MARC
tag that allows you to search for an authority, and link it.
In MARC21: all authority data is copied over (authid in $9).
In UNIMARC: all authority data is copied over (authid in $9).
NOTE: after linking, you may have to expand the MARC tag you
chose so that subfield $9 becomes visible.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended-by: Jonathan Druart
Tidy C4/Search.pm
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
After adding ConsiderHeadingUse system preference we can limit search
results of authority finder plugin to authorities useable in specyfic
type of fields (based on 008/14-16 data in authorities record).
The autocomplete feature in auth_finder.pl should obey the ConsiderHeadingUse
setting.
Test plan:
==========
0. Have a standard KTD enviromnent.
1. Apply Bug 38494.
2. Set ConsiderHeadingUse system preference to "Don't", ShowHeadingUse to
'Show'.
3. Go to the Cataloging editor and open the authority finder plugin for
the 650 field.
4. Type "Application" in "Search main heading ($a only)" field.
5. Notice two autocomplete values: "Application program interfaces
(Computer software)" and "Application software".
6. Click search button.
7. There are two result: "Application program interfaces (Computer
software)" (the one with 'v' Subject in Heading Use column) and
Application software Development (with 'x' Subject in Heading Use
column).
8. Close the authority finder window, cancel the editor. Set
ConsiderHeadingUse system preference to "Do".
9. Go to the Cataloging editor and open the authority finder plugin for
the 650 field.
10. Type "Application" in "Search main heading ($a only)" field.
11. Notice two autocomplete values: "Application program interfaces
(Computer software)" and "Application software".
12. Click search button.
13. There is only one result: "Application program interfaces (Computer
software)" (the one with 'v' Subject in Heading Use column).
So we get only one result but there were two autocomplete hints.
14. Apply the patch ; restart all ; clear the browser js cache (or go to
a private browser window).
15. Repeat p. 9-10.
16. Notice that there is only one autocomplete hint: "Application
program interfaces (Computer software)".
17. Click search button.
18. There is only one result: "Application program interfaces (Computer
software)" (the one with 'v' Subject in Heading Use column).
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In order to remove false positives with the QA script we should replace some tabs with spaces.
There are more but I wanted to make sure no regression would be
introduced
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If a subfield is present in the authority record, but this subfield is
marked as 'Hide all', then if you edit and save such a record, the
data from hidden fields wil be lost forever. This behavior differs
from bibliographic records editor, when even if a subfield is hidden
(not active) in the editor it will be activated and present in the
editor if present in the record.
The problem affect above all records imported from external agencies.
Test plan:
==========
1. Have any authority record. Note one present subfield (e.g. 100 $d).
2. Modify the record framework for this type of record
(/cgi-bin/koha/admin/authtypes.pl), marking the subfield 'Hide all'.
3. Open the record in the editor and save.
4. Re-enable the subfield in the framework, marking it as 'Show all' now.
5. Reopen the record in the editor. Note that the previous content of
the subfield you played with is gone. Enter any new value and save.
6. Apply the patch ; restart all.
7. Repeat p. 2, i.e. hide the subfield again. Open the record in
the editor. You should see the content of the hidden field as you
would for a bibliographic record with a subfield hidden in the editor
but present in a record. (Note also that the content of this subfield
is visible in record view).
8. Open the editor with an empty record (New authority) of the type
in question. Control that the subfield is hidden (not accessible)
for a new record.
BTW Note that the "hidden" but present subfields are visible in OPAC,
but not in the staff interface *before* applying the patch. The patch
changes nothing for OPAC.
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Strings as YYYY, MM, DD put as part of default value for authorities
are interpreted as year (four digits), month and day. YY is missing
(two digits year). BTW, for bibliographic records it is <YYYY>, <YY>,
<MM>, <DD> (in Koha/UI/Form/Builder/Biblio.pm).
Test plan:
==========
1. Edit an authority framework of your choice
(/cgi-bin/koha/admin/authtypes.pl), inserting a default value that
contains YY for a known field.
2. Create a new authority record of the chosen type. Control the field
for which a default value was defined. You should see YY.
3. Apply the patch ; restart_all.
4. Repeat p. 2. There should be a current year (two digits, like '25')
in place of YY.
Signed-off-by: esther <esther@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
In MARC 21 authority records, three bytes (008/14-16) indicate what the
heading can be used for (main/added entry, subject entry, series entry).
Koha should be able to respect the record's intended use in authority
search during cataloging, provided that the authority file is well
formed. Also, we should be able to decide between more strict but
correct behavior and current lax behavior.
Test plan:
----------
1. Apply the patch; updatedatabase ; restart_all
2. Set the ShowHeadingUse system preference to ‘Show’
3. Go to the Cataloging editor and open the authority finder plugin for
the 100 field. Search for Peter. With standard ktd test data you should
get 9 results, some with ‘v’ before Main/Added Entry, some with ‘x’.
These with ‘x’ are not to be used in this context, provided you use a
well-formed authority file
4. Set ConsiderHeadingUse system preference to ‘Do’
5. Repeat p. 3. You should get now only 4 Peters – those with ‘v’
before Main/Added Entry (008/14 = ‘a’)
6. You can repeat the test for subject headings (6XX) and series
headings (sometimes you would have to modify the test data, e.g. there
are few authority records with 008/16 = ‘a’ (series use)
7. This should work equally with Zebra and with Elasticsearch
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This is to avoid using private jQuery method _data.
Here's what jQuery 1.8.0 release notes says about it:
"this is not a supported public interface; the actual data structures
may change incompatibly from version to version."
So we should not rely on it.
What this patch does is use event delegation [1].
Events are bound to a parent container, so when elements are added
dynamically inside that container, we don't need to re-attach event
handlers manually
This patch also comes with a bit of cleanup, and introduce "breaking
changes" (they are breaking changes only if you happen to have custom
framework plugins):
1) 'mouseover', 'mousemove', 'keypress' events are no longer listened to
'mouseover' and 'mousemove' are not used and would trigger too much
events.
'keypress' is also not used, and is deprecated
2) Event handlers now takes a single parameter that is an Event object
It just makes the code a lot less complicated.
3) Event handlers do not pollute the global scope anymore
[1] https://learn.jquery.com/events/event-delegation/
Test plan:
- Go to every page that has a MARC editor and verify that plugins still
work. This includes addbiblio.pl, additem.pl, authorities.pl,
neworderempty.pl, orderreceive.pl
- Test plugins that use 'focus' event (for instance barcode.pl), 'blur'
event (callnumber.pl) and 'click' event (almost all the others)
- Test that plugins work on cloned fields/subfields
Rebased-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When linking authorities with other authorities in UNIMARC
instances it would be good if Koha automatically copied the
contents of subfield 010$a [aka INTERNATIONAL STANDARD NAME
IDENTIFIER (ISNI)] into the corresponding 5xx$o subfield
(should such an ISNI number exist in the source record).
This patch enables the enhancement outlined above.
For more information, please see the offical IFLA UNIMARC
Authorities Format Manual (online ed., 1.0.0, 2023), pp. 350,
363, 385. This is actually where we got this idea from ;-)
Note #1: it only applies to the Personal Name, Corporate
Body Name, and Family Name authority types.
Note #2: the default MARC Authorities framework that ships
with UNIMARC Koha instances does *not* include a
subfield $o for fields
200 (Authorized Access Point - Personal Name),
210 (Authorized Access Point - Corporate Body Name),
220 (Authorized Access Point - Family Name).
This is per the offical IFLA Manual, and effectively
means we can push the ISNI number to the same array
used for other subfields (@subfield_loop) without
worrying about overwriting any previous value.
Test plan:
0) Have a UNIMARC Koha test instance up and running. Then,
carry out the following steps in the Staff interface.
1) Stage for import the sample MARC authority data attached
to this Bug report (filename: sample-auths.mrc, contains
one Personal, one Corporate Body, and one Family Name).
Go to 'Cataloging > Stage records for import' and upload
the file. Make sure you select 'Authority' in the 'Record
type' dropdown menu. Leave all other settings untouched at
their default values. Click the 'Stage for import' button.
Then, import the staged records into your Catalog. Go
to 'Cataloging > Manage staged records'. Click on the
filename link in the second column. At the bottom of the
page, confirm you can see all three authorities included
in the .mrc you uploaded, then click on the button named
'Import this batch into the catalog'.
2) Enable the authority finder plugin for authority fields
500, 510 and 520. This can be done as follows:
a) Go to 'Administration > Authority types' and click on
'Actions->MARC structure' for the 'NP' (Personal Name)
authority type.
b) Search for tag 500; then click on 'Actions->Subfields'
for that tag.
c) Click 'Edit' next to subfield 'a' (Entry element), then
pick 'NP' from the 'Thesaurus' dropdown menu. Save your
settings and you're good to go! When editing a Personal
Name authority from now on, the 'Tag editor' button next
to subfield 500$a will launch the authority finder.
Repeat b) and c): search for tag 510, edit $a, pick 'CO'.
Repeat b) and c): search for tag 520, edit $a, pick 'FAM'.
3) Go to Koha's 'Authorities' module. At the top search bar,
filter on Personal Name authorities and perform a search.
Pick any one of the results, and edit it. Go to tab '5',
expand field 500 and use the button next to subfield $a
to launch the authority finder. Type '0000' inside the
'Search entire record:' text box, and click on 'Search',
then 'Choose'.
Notice that the ISNI number from the source record did
*not* get copied to subfield 500$o. The same will happen
if you try to Choose an authority for field 510 and 520.
4) Apply this patch.
5) Repeat step 3), this time the ISNI number from the source
record will be copied to 500/510/520 $o automatically!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This adds a new system preference 'AuthorityXSLTDetailsDisplay'.
If set, authority MARCXML will be transformed using the XSLT
at the given filename or URL.
The HTML output will be displayed in place of tabs in details page.
The syspref value can contain {langcode} and {authtypecode} which will
be replaced by the appropriate value (resp. current language and
authority type code).
Test plan:
1) Apply patch and run updatedatabase
2) Search for an authority type GEOGR_NAME and view details page
3) Verify that display is not affected yet
4) Create an XSLT file (for example in /home/koha/xslt/en/GEOGR_NAME.xsl)
5) Set 'AuthorityXSLTDetailsDisplay' system preference to :
/home/koha/xslt/{langcode}/{authtypecode}.xsl
6) Refresh details page
7) Verify that display matches what you expect from the XSLT
8) Set 'AuthorityXSLTDetailsDisplay' system preference to :
<path to sources>/koha-tmpl/intranet-tmpl/prog/en/xslt/UNIMARCauthDetails.xsl
8) Refresh details page
9) Verify that display matches what you expect from your XSLT
Example of a minimal XSLT:
<?xml version='1.0' encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:marc="http://www.loc.gov/MARC21/slim"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes"/>
<xsl:template match="marc:record">
<xsl:element name="div">
<xsl:attribute name="class">
<xsl:text>authority-summary</xsl:text>
</xsl:attribute>
<xsl:value-of select="marc:datafield[@tag='151']/marc:subfield[@code='a']"/>
</xsl:element>
</xsl:template>
</xsl:stylesheet>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It has probably never been used. There's no sign of any UI to delete from
the authority editor or auth_finder in the last 13 years of templates, and
it was unused when it landed; the patch that actually made the first patch
work, a month later, put deleting authorities in authorities_home.pl, where
it has been ever since.
It certainly hasn't been used since bug 17600 landed in 2021, since it
doesn't 'use C4::AuthoritiesMarc qw( DelAuthority );' and so if you try to
use it you just get an error for your trouble.
Sponsored-by: Chetco Community Public Library
Signed-off-by: Yanjun Li <yanjun.li@bywatersolutions.com>
Amended-by: Jonathan Druart
tidy
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When viewing an authority record, you have the option to "Save" in
several different formats. This operation is a GET operation and the
script should not be looking for a "cud-" operation.
To test you should have at least one authority record.
- Apply the patch and go to Authorities.
- Perform an authority search which will return one or more records.
- View the details of an authority record.
- From the toolbar, test the "Save" option*
* Note: In my test the export choice "MADS (XML)" resulted in a
zero-byte file but I'm assuming that is a separate issue.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Merging two different authorities types can result in the loss of some
field. This patch adds a warning when merging different type of
authorities and add more display of authorities types during merge.
To test:
1- Find two authorities you what to merge. Be sure that these
authorities have different type
2- Search for these authorities (be sure to have both results on the
results page)
3- For the first authority click on "Actions" then on "Merge", same for
the second one
4- Check that koha is asking you to choose a framework and that
authority types are not displayed
5- Choose a framework, then click on next
6- Check that the authority type is not displayed in the tabs and that
no warning appear
7- Apply the patch
8- Repeat step 1 to 3 again
9- Check that authority type is now displayed next to their ID
10- Repeate setp 5 again
11- Check that the authority types is now displayed in the tabs next to
their ID and that a warning appear
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Linking an authority subfield to an authorized value just leaves a blank
in the form rather than creating a <select>, because there's a stray cud-
in the type returned from build_authorized_values_list.
Test plan:
1. Without the patch, Administration - Authority types - Actions menu for
Default - MARC Structure
2. Actions menu for 040 - Subfields
3. Edit subfields - Tab b - Authorized value - set to LANG - Save changes
4. Authorities - New authority - Default
5. In 040 tag, click CATALOGING SOURCE to expand the tag
6. Note that subfield b has a blank space rather than a dropdown menu
7. Apply patch, restart_all
8. Authorities - New authority - Default
9. In 040 tag, click CATALOGING SOURCE to expand the tag
10. Note that subfield b has a dropdown menu listing language names
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It happens that librarians to save time open an authority editor by putting
in the URL, by hand, the authid prefixed, by mistake, with a blank (e.g.
.../authorities.pl?authid= 100 -- mind the space before 100). In
such a case the editor opens with the right auth record (i.e. 100) but,
after saving the record, the content of the authid MARC field (001 for
a standard MARC 21 installation) results modified and contains
additional initial blanks.
Moreover, if the heading (1XX field) was modified in the authority record
during such an edit, the changes will not propagate to the linked
bibliographic records. And won't in the future.
This is because in the authorities.pl script $authid is taken (and
continuously used) directly from CGI parameter, without any
validation and/or correction (line 540 in the current main branch).
Test plan:
==========
1. Open an auth record in the editor with an added space before
authid value, e.g.:
http://ktd:8081/cgi-bin/koha/authorities/detail.pl?authid= 100
Modify the heading field -- in the ktd data set:
150 Computerized typesetting
Save the record.
2. a) Open the record for editing again--see the space added before
the authid in field 001. Close the editor (with Cancel).
b) Try to go to the linked biblio records with Used in X records.
Note no results, if using ES.
c) Remove the space before authid (after an:) in the URL.
Go to the linked biblio records. See that the content of
the field controlled by the modified auth record did not
update.
3. Apply the patch; restart_all.
4. Repeat p. 1 and 2 with a different authid. Everything should
be OK now.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Go to the Authorities module and do a Z39.50 search that will return
results (e.g. a general subject heading)
2. Import an authority record from the results
--> Confirm that the record is imported into the editor
3. Authorities > New, replace it via Z39.50, confirm it's imported
4. Authorities > New, fill the required fields, confirm it saves
5. Edit an existing authority, replace it via Z39.50, confirm it saves
6. Edit an existing authority, replace authid=nn in the URL with a
number that doesn't exist like 1000000, confirm you get a 404 page
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Janusz Kaczmarek <januszop@gmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When trying to open the authority editor with authid=<invalid_authid>
(e.g. a deleted authid) Koha explodes with a message:
Can't call method "authtypecode" on an undefined value at
/kohadevbox/koha/authorities/authorities.pl line 556
This this because authtypecode method is called on the result of
->find without verifying that it was succesful.
Test plan:
==========
1. Try to edit an auth rec. giving as a authid (in URL) a non-existing
authid, e.g. in ktd, with standard ktd test data:
http://your_ktd:8081/cgi-bin/koha/authorities/authorities.pl?authid=100000
Koha should explode with the message:
Can't call method "authtypecode" on an undefined value at
/kohadevbox/koha/authorities/authorities.pl line 556
2. Apply the patch; restart_all.
3. Repeat p. 1. You should get the 404 error page.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
A Marcel's QA patch to Bug 36552 added use POSIX; in two spots.
In https://metacpan.org/pod/POSIX we read:
CAVEATS
Everything is exported by default (with a handful of exceptions). This is
an unfortunate backwards compatibility feature and its use is strongly
discouraged. You should either prevent the exporting (by saying use
POSIX ();, as usual) and then use fully qualified names (e.g.
POSIX::SEEK_END), or give an explicit import list. If you
do neither and opt for the default (as in use POSIX;), you will
import hundreds and hundreds of symbols into your namespace.
This patch fixes this.
No test plan.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Theoretically, it might be empty? Note the check too in the
other script.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The 'date entered on file' (MARC21: 008/0-5, UNIMARC: 100a/0=7) of a record created
by duplication of an existing record should be set to the current date instead of
having the value of the original record.
Test plan
=========
1. Check the 'date entered on file' of an existing biblio / authotiry record
(MARC21: 008/0-5, UNIMARC: 100a/0=7).
2. Duplicate the record by Edit > Edit as new (duplicate)
3. Control the 'date entered on file' value - it will equal to that of the
original record.
4. Apply the patch (restart plack).
5. Repeat step 2.
6. Check the date - it should be the current date.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The authority finder just does a GET for a list of search results, it
doesn't create or update or delete, so the template that thinks the op
is do_search is correct.
Test plan:
1. Cataloging - New record
2. In the 1 tab click the Tag editor icon at the end of 100 subfield a
3. In the popup, click Search, and nothing happens, no results are shown.
4. Apply patch, reset_all
5. Repeat steps 1-3, see that you get results.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
1. Set AuthorityXSLTResultsDisplay to a valid XSL file (see bug 30554
attachments, there is an example XSL file)
2. Go to the bibliographic record editor (edit an existing one or create
a new one)
3. Find a field linked to authorities and open the plugin
4. Start a search and verify that the results are displayed using the
XSLT output (if using the example file it should be a link saying
"Authority #<authid>")
Sponsored-by: Écoles nationales supérieure d'architecture (ENSA)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We should no longer need to check CSRF token from pl files
TODO - there is a change for some files where we returned 403
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We do not longer need to generate_csrf from pl files
TODO - members/boraccount.tt and sco/sco-main.tt needs to be adjusted
Bug 34478: [TO SQUASH] Remove generate_csrf from pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Rather than test that nothing is returned, we want to test that the terms are filtered as expected. This also avoids the possibility of the tests failing in a db where there is a record for Donald Duck
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We are dealing ok with ES exceptions for biblio records search,
catching them and raising them to the end user. But we don't for
authorities, where we explode with an ugly 500.
Test plan:
Search for "(term_1*) AND (-) AND (term_2*)" in the authority search and
notice that you don't get a 500 but an error instead saying that you
should try again
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Both Elastic and Zebra search_auth_compat return a hash key
authid for a result.
Test plan:
Remove an authority that should be in your results list.
Note that it is no longer marked as pending, but just not displayed.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When an authority is removed from the result list it is not removed from
the search engine yet.
This patch suggests to add a note in the summary column to tell the user
that the deletion is pending.
Test plan:
1 - Go to authorities home and perform a search;
2 - Delete any authority;
3 - After the confirmation, the page is refreshed but still contains the
deleted authority, with a red note explaining that the deletion is
pending.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run git grep "specifique key"
Run git grep "the fonction"
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the ability to change the authority MARC framework/type
being used while editing an authority record.
To test:
1) Log into the staff client and go to Authorities
2) Search for an existing authority and edit it
3) Notice there is no way to change this authority type
4) Apply patch, restart services, refresh editor in browser
5) Notice the new Settings dropdown. Click to open
6) Confirm the correct current authority type is selected
7) Select another type to change to that. The page should reload
8) Confirm the page reloads with the correct authority type framework
loaded and the MARC data is still correct
Sponsored-by: Education Services Australia SCIS
Signed-off-by: Jacob O'Mara <jacob.omara@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the case of importing a record to the
ApplyFrameworkDefaults options.
To test:
1. Update database
2. Confirm the ApplyFrameworkDefaults system preference now has the
'when importing a record via z39.50' option. Do not select it.
3. Go to Cataloguing. Import a record from z39.50, or replace an
existing record.
4. Confirm framework defaults are not applied.
5. Go back to the system preference and check the 'when importing a
record via z39.50' option.
6. Repeat step 3. This time framework defaults should be applied. Only
fields that are empty in the imported record will be replaced by
framework defaults.
7. Repeat for authorities.
Sponsored-by: Catalyst IT
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a system preference ApplyFrameworkDefaults to configure
when to apply framework defaults - when cataloguing a new record, when
editing a record as new (duplicating), or when changing the framework
while editing an existing record. This applies to both bibliographic
records and authority records.
To test:
1. Update database
2. Go to Administration -> system preferences. Find the
ApplyFrameworkDefaults system preference. Confirm "when cataloguing new
records" is selected by default.
3. Keep the system preference open in one tab, and open the staff client
in another tab.
4. Go to Administration -> bibliographic frameworks. Choose a framework,
edit the subfields for a tag, and give a subfield a default value. For
example, set 500$a for the BOOKS framework to have a default value of
"TEST". This will be Framework A.
5. Ensure you have another framework that does not have the same default
value for a subfield as Framework A. This will be Framework B.
6. Go to Cataloguing. Add a new record using Framework A. Confirm your
subfield has the default value filled. Cancel and do not save the
record.
7. In your System preferences tab, uncheck the option "when cataloguing
new records" and save. No options should now be selected.
8. In our other tab, go to cataloguing, add a new record using Framework
A. Confirm your subfield does NOT have the default value filled. Fill
the required fields, including the subfield that should have a default
value, and Save the record.
9. In your system preferences tab, select all options and save.
10. In your other tab, click Edit, then "Edit as new (duplicate)".
Confirm your subfield has maintained the value from the source record.
Cancel and do not save the record.
11. Edit your original record and delete the value in your subfield that
could be filled with a default value by the framework. Save the record
with no value in the subfield.
12. Click Edit, then "Edit as new (duplicate)". Confirm your subfield
has the default value filled. Framework defaults will only apply to
emplty fields. Save the record.
13. Do a catalogue search and find a record that uses Framework B.
14. If you need to, edit the record to make sure there is nothing in your
subfield that should have a default value if this record were to use
Framework A, and Save.
15. Edit the record. Using the settings dropdown, change the framework
to Framework A. Confirm your subfield has the default value filled.
16. Repeat steps 4 to 12 with authority types and authority records.
Sponsored-by: Education Services Australia SCIS
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
MARC::Record and MARC::File::* modules sometimes use the position 09 of
the leader to detect encoding. A blank character means 'MARC-8' while an
'a' means 'UTF-8'.
In a UNIMARC authority this position is used to store the authority type
(see https://www.transition-bibliographique.fr/wp-content/uploads/2021/02/AIntroLabel-2004.pdf [FR]).
In this case, 'a' means 'Personal Name'.
The result is that the import will succeed for a Personal Name
authority, but it will fail for all other authority types.
Steps to reproduce:
0. Be sure to have a Koha UNIMARC instance.
1. Download the MARCXML for "Honoré de Balzac"
curl -o balzac.marcxml https://www.idref.fr/02670305X.xml
2. Verify that it's encoded in UTF-8
file balzac.marcxml
(should output "balzac.marcxml: XML 1.0 document, UTF-8 Unicode
text")
3. Go to Tools » Stage MARC for import and import balzac.marcxml with
the following settings:
Record type: Authority
Character encoding: UTF-8
Format: MARCXML
Do not touch the other settings
4. Once imported, go to the staged MARC management tool and find your
batch. Click on the authority title "Balzac Honoré de 1799-1850" to
show the MARC inside a modal window. There should be no encoding
issue.
5. Write down the imported record id (the number in column '#') and go
to the MARC authority editor. Replace all URL parameters by
'breedingid=THE_ID_YOU_WROTE_DOWN'
The URL should look like this:
/cgi-bin/koha/authorities/authorities.pl?breedingid=198
You should see no encoding issues. Do not save the record.
6. Import the batch into the catalog. Verify that the authority record
has no encoding issue.
7. Now download the MARCXML for "Athènes (Grèce)"
curl -o athènes.marcxml https://www.idref.fr/027290530.xml
8. Repeat steps 2 to 6 using athènes.marcxml file. At steps 4 and 5 you
should see encoding issues and that the position 9 of the leader was
rewritten from 'c' to 'a'. Strangely, importing this batch fix the
encoding issue, but we still lose the information in position 09 of
the leader
This patch makes use of the MARCXML representation of the record instead
of the ISO2709 representation, because, unlike
MARC::Record::new_from_usmarc, MARC::Record::new_from_xml allows us to
pass directly the encoding and the format, which prevents data to be
double encoded when position 09 of the leader is different that 'a'
Test plan:
- Follow the "steps to reproduce" above and verify that you have no
encoding issues.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When upgrading an authority with Z39.50, the field 2XX is sent into the
research grid.
The field 210a is sent into the search field "Author
(meeting/conference)". Or a collective authority is more often a
corporation than and meeting so librarian has to copy and paste this
data. (In unimarc field 210a is used both for corporation and meeting.)
This patch makes 210a field be sent into the search field "Author
(corporate)" instead of the "Author (meeting/conference)" one.
1- Find an authority with collectivity type (with a field 210a).
2- Click on "Edit" then on "Edit record"
3- Click on "Replace record via Z39.50/SRU search"
4- See that the field 210 is reported in the search grid in "Author
(meeting/conference)" field
5- Apply the patch
6- Go throug step 1 to 3 again
7- See that the field 210 is now reported in the search grid in "Author
(corporate)" field
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Andreas Roussos
Petro Vashchuk
Tomas Cohen Arazi
Janusz Kaczmarek
Jonathan Druart
Marcel de Rooy
Julian Maurice
Koha Development Team
Fridolin Somers
Phil Ringnalda
Owen Leonard
Nick Clemens
Marion Durand
Emily Lamancusa
jeremy breuillard
Kyle M Hall
Aleisha Amohia