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>
(cherry picked from commit 8d9ccd6fc3)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit ca023b334c)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
(cherry picked from commit 4b66fbc4eb)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 65e1816bba)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
(cherry picked from commit cc834ba187)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 7c4ea8ee7f)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
(cherry picked from commit dd8f9e1266)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 0cd9d2f184)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
(cherry picked from commit 01e2a6d983)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit b63d96612b)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
(cherry picked from commit 1aba01adb4)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit aa7bea04c4)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
(cherry picked from commit 18843cabdb)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit b9ba92c153)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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>
(cherry picked from commit 3d7b60dc90)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 09b29d06da)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
Currently when show an authority record you can see the count of records linked
with that authority, but when edit that authority record the that detail is
dissapeared.
Applying this patch will have that information also on edit mode of authority.
Test plan:
1) Search for an authority that is already connected with at least one record
2) On detail view of an authority you can check that authority is linked with
x records.
3) Edit that authority and the information about in how many records that
authority is linked is missing.
4) Apply this patch
5) Edit again that authrity and you can find now the count in how many records
is used that authority
Signed-off-by: Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch only affects authority search results in the staff interface.
It adds a new system preference AuthorityXSLTResultsDisplay. If set,
each authority search result MARCXML will be transformed using the XSLT
at the given filename or URL. The output will be displayed in place of
the default summary.
If errors occur, the XSLT is ignored and the default summary is
displayed.
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. Verify that authority search results are not affected yet.
3. Create an XSLT file (for instance in
/home/koha/xslt/en/GEOGR_NAME.xsl)
4. Set AuthorityXSLTResultsDisplay syspref value to
/home/koha/xslt/{langcode}/{authtypecode}.xsl
5. Do an authority search that returns GEOGR_NAME results. Verify that
the summary matches what you expect from your XSLT
6. Do an authority search that returns authorities of other types.
Verify that the default summary is displayed.
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: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Note: The check in build_authorized_values_list with defaultvalue can be
simplified since $value may already contain the defaultvalue. It is filled
before the sub is called.
The test for inserting a blank option is generalized; and may be still
improved when using required attributes in the template? Note that we
might experience some browser issues for these placeholders.
Removed a few useless lines with respect to fields controlled
by itemtypes. The last assignment to $value was useless and
its probable intention unwanted (just use defaultvalue).
Test plan:
Put a defaultvalue in an authority framework.
Add a new authority. Check for that value.
Open existing authority. Clear field, save and reopen. Check if
field is still empty.
Bonus: test field controlled by authorised values.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The previous patch makes check_cookie_auth return the session instead of
$sessionID, so we are adjusting the different calls to prevent
confusion.
However they are mainly used to check the authentication status and
don't care about this second variable.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "tabloop" variable that is passed from the add item form logic to the cataloguing plugins.
But there is confusion, sometimes it's an iterator ($i) and sometimes (batchMod.pl) an array.
Actually this tabloop variable is never used from cataloguing plugins, we should remove it.
Test plan:
Read the code and confirm the above.
You can also test a couple of plugins and confirm that they are still
working.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
For names and uniform titles, when you do a z39.50 search from an authority
record, we prefill what's in the relevant tag's subfield a in the search
form, but for subjects, we don't, both because GetMandatoryFieldZ3950 thinks
the param is topic when it's actually subject, and because
z3950_auth_search.tt doesn't bother putting the value of &subject into the
form.
Test plan:
1) Authorities - New authority - Topical Term
2) Tab 1, click on HEADING-TOPICAL TERM to expand subfields
3) In subfield a, type goats
4) Click Z39.50/SRU search and verify that the Subject heading search field
has goats prefilled
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same patch for the authority frameworks/records
Sponsored-by: Orex Digital
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
add authority type in the form to create the missing authority.
when authority was found, the 600$9 field have the authid.
Testing scenario (Creating an authority record for a failed automatic link) :
1 - In your system preferences set:
AutoCreateAuthorities: Don't generate
BiblioAddsAuthorities: Allow
2 - Go to the Cataloging -> New record (koha/cataloguing/addbiblio.pl)
Ensure you are using the basic editor
3 - Click the "Link authorities automatically" button.
A message should appear, telling the user "No authority link was changed."
4 - Add random informations in field 600$a of the biblio record.
5 - Click the "Link authorities automatically" button.
the message box should now show "600 - No matching authority found.".
the 9 subfield is red
Above the 9 subfield is a red X with a blue plus next to it
Hover on the plus, see it is titled 'Create authority'
6 - Click the 'Create authority' link
7 - A new authroity form pops up, the info from the cataloging editor is prefilled
Click the 100 field heading to expand and confirm info is transferred
8 - Fill in necessary fields and save the new authority
9 - The cataloging screen now has the 9 subfield populated and is green
10 - Click "Link authorities automatically" again
Dialog says "No authority link was changed"
11 - In another tab go to System preferences and set AutoCreateAuthorities to 'Generate'
12 - Add random information to the 650 field
13 - Click 'Link authorities' button
14 - Dialog says:650 - No matching authority found. A new authority was created automatically.
15 - The subfield 9 is green and has the id of the new authority record
16 - In another tab search authorities and find an existing subject heading
17 - Add a new 650 with the info from the existing record
18 - Click 'Link authorities'
19 - The new field is correctly linked to existing authority
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=12299
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Same as the first patch but when cataloguing an authority record
Sponsored-by: Orex Digital
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch modifies the script and template for showing the details of
an authority record so that if the authority subfield is configured to
be a link the link is correctly output in the template.
To test you must have an authority type configured with at least one
subfield designated as a URL:
- Go to Administration -> Authority types
- Select "MARC structure" from the actions menu for the authority type
you want to modify.
- Select "Subfields" from the actions menu for the tag containing
the subfield you want to modify (for instance 856).
- Edit the subfield you want to display as a link (e.g. subfield u).
- In the subfield configuration form under "Advanced constraints" check
the "Is a URL" checkbox and save your changes.
- Apply the patch and go to Authorities in the staff interface.
- Search for or create an authority record which contains URL
information in the right subfield (for instance 856$u).
- View the details for the record. Using the 856 example, the "8" tab
should contain an active link pointing to the correct URL.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Lines can be moved. Deletion can be done too if skip_merge is not set.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If you merge A to B, we should remove older AA merges (regular
merge to itself) in the queue before deleting A.
Test plan:
[1] Set merge limit in prefs to say X.
[2] Find three authorities A, B, C with linkcount >X, >X, <X.
[3] Merge C to B. This creates a 'BB merge' in the queue.
Auth C is deleted.
[4] Merge B to A. Creating AA and BA in the queue.
Auth B is deleted.
Optionally verify that BB is no longer in the queue.
[5] Run the merge_authorities.pl cron job.
Verify that the linkcount to A is the former total of ABC.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Phil Ringnalda <philringnalda@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - Apply patch, update database
2 - Note new syspref 'DumpSearchQueryTemplate'
3 - Leave it off
4 - Enable DumpTemplateVariablesOpac and Staff
5 - Search on staff and opac
6 - View the source
7 - Search for 'search_query' - you shouldn't find it
8 - Enable the new pref
9 - Repeat, but you should find the query
10 - Test staff/opac search and advanced search, cataloguing search, authority search, authfinder search, adding to a basket form a new biblio
11 - All should work and show the query
12 - This will work under both ES and Zebra
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1. Review code of the following files and confirm that 'use Modern::Perl;' is used in place of
'use strict; use warnings;'
auth_finder.pl
authorities-home.pl
authorities.pl
blinddetail-biblio-search.pl
detail-biblio-search.pl
detail.pl
export.pl
merge.pl
merge_ajax.pl
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Instead of dying!
Test plan:
Assuming you have a patron with borrowernumber=51 and another one that
can be deleted with borrowernumber=42
- authorities-home.pl
* Delete an authority record
* hit /cgi-bin/koha/authorities/authorities-home.pl?op=delete
- basket/sendbasket.pl
* Send a basket to someone
* hit /cgi-bin/koha/basket/sendbasket.pl?email_add=1
- members/apikeys.pl
* Generate and delete an API key for a patron
* hit /cgi-bin/koha/members/apikeys.pl?patron_id=51&op=delete
- members/deletemem.pl
* Delete a patron
* hit /cgi-bin/koha/members/deletemem.pl?member=42&op=delete_confirmed
- members/mancredit.pl
* Add a manual credit
* hit /cgi-bin/koha/members/mancredit.pl?borrowernumber=51&add=1
- members/maninvoice.pl
* Add a manual invoice
* hit /cgi-bin/koha/members/maninvoice.pl?borrowernumber=51&add=1
- members/member-flags.pl
* Change permissions for a patron
* hit /cgi-bin/koha/members/member-flags.pl?member=51&newflags=1
- members/member-password.pl
* Change the password for a patron (from the staff interface)
* hit /cgi-bin/koha/members/member-password.pl?member=51&newpassword=aA1
- members/memberentry.pl
* Edit some patron's info
* hit /cgi-bin/koha/members/memberentry.pl?borrowernumber=51&op=save
- members/paycollect.pl
* Pay an individual fine
* hit something like /cgi-bin/koha/members/paycollect.pl?borrowernumber=51&pay_individual=1&accounttype=L&amount=1.00&amountoutstanding=1.00&accountlines_id=157&paid=1
You may need to edit some values
- tools/import_borrowers.pl
* Import some patrons
* hit /cgi-bin/koha/tools/import_borrowers.pl?uploadborrowers=1
- tools/picture-upload.pl
* Upload an image for a patron
* You will need to edit the html content
hit Home › Tools › Upload patron images
then locate the csrf_token input and modify its value
Note for QA:
- Opac is not done as blocking_errors.inc does not exist for this
interface
- ill/ill-requests.pl
I did not manage to replace this occurrence
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In several places we escape quotation marks using
$value =~ s/"/"/g;
All the occurrences are wrong and must be removed.
Most of them are leftover of bug 11638 (Remove HTML from
addbiblio.pl), which removes the construction of html from pl scripts.
The problem has been highlighted by bug 13618, I did not track down why
the issue did not exist before (?)
Test plan:
0/ Use strings with quotation marks, like:
'Fiddle tune history : "bad" tunes'
You can also use other html characters to make the tests more complete,
like 'Fiddle tune history : <"bad" tunes>'
1/ authorities/authorities.pl
a. Edit an authority filling different fields with quotation marks
b. Edit it again
=> The display (inputs' values) is wrong, if you save the escaped quotes
will be inserted
2/ cataloguing/addbiblio.pl
Same editing a bibliographic record
3/ cataloguing/additem.pl
Same editing items
4/ members/memberentry.pl
Edit a patron's record and fill some fields with quotation marks
+ fields borrowernotes and opacnotes
=> The quotes are inserted directly in DB (escape is done before the
insert!)
5/ opac/opac-review.pl
For QA only: $js_ok_review is never used
6/ tools/batchMod.pl
For QA only: $value is always undefined at that point
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 20261 introduced an error because search_auth_compat responded
differently for ES and Zebra, now bug 19365 fixed the underlying
difference. This patch restores previous code to fix pagination.
Additionally we add a fix for 10000+ results in ES and remove a double
import of C4::Auth
To test:
1 - Perform an authorities search with 1+ pages using Zebra
2 - Page through results, note you are only offseeting by 1 each time
3 - Perform an authorities search with 10,000+ results in ES
4 - Click on the last page and get an error
5 - Apply patch
6 - Retry Zebra search
7 - Results should paginate correctly
8 - Clicking on last page should return last results
9 - Retry ES results
10 - Results should paginate correct
11 - Clicking on last page should return last results
Signed-off-by: Ere Maijala <ere.maijala@helsinki.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The 'New authority' button does not always list the available
authority types in A-Z order based on their description.
This patch fixes that.
Test plan:
1) Go to Home > Authorities in the staff client; notice how the
'New authority' button lists auth types sorted by description.
2) Go to an authority's detail page; notice how the same 'New
authority' button will list auth types sorted by their code.
3) Apply the patch.
4) In an authority's detail page, the 'New authority' button will
now list the available authority types sorted by description.
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In the staff client, when you perform an authority search the
selected values for the 'Search all headings:' and 'Search
entire record:' options get shuffled around when you click on
the 'Search' button.
This patch fixes that.
Test plan:
1) Perform an authority search and set the 'Search all headings:'
option to 'starts with'.
2) Click on the 'Search' button.
3) Notice how the 'Search all headings:' option is now 'contains',
and 'starts with' has moved down to the 'Search entire record:'
option.
4) Apply the patch.
5) Hit 'Search' again. This time the selected search options do
not move around.
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The reported issue was:
On field 606, if I use an Authority with multiple "x" subfields, it will
add just the first "x"
Error in the logs:
Odd number of elements in anonymous hash at /home/vagrant/kohaclone/authorities/blinddetail-biblio-search.pl line 97.
We should pass a ref (!), caused by
commit a7df1f9f8e
Bug 18904: (follow-up) Retrieve subfield in the order they are stored
Test plan:
Edit an authority and add several $x to 600
Link this authority to a bibliographic record
=> Without this patch only the first subfield is copied
=> With this patch applied they are all copied
Signed-off-by: José Anjos <joseanjos@gmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
