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>
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>
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>
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>
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>
Script authorities.pl still contains a module 2 calculation on the hidden
attribute, although it is used as a boolean.
Since -5 mod 2 == 1, it does no harm, but we better remove it.
Test plan:
Edit and save an authority. Verify that everything still works as expected.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Although we could argue that the user should make all $9 subfields
visible, this might be a good compromise. It selectively reverts the
change from the first patch by accepting $9 subfields without checking
the hidden flag in the framework.
Test plan:
[1] Make a subfield $9 visible for some authority field.
[2] Put a value in it somewhere in authorities.pl
[3] Make subfield $9 invisible in the auth framework.
[4] Open and save the adjusted authority record.
[5] Check the marcxml of this record.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
[1] Replace corrosponding => corresponding
[2] Replace containts => contains
[3] Replace item_level-itypes => item-level_itypes
[4] Replace Managment => Management
[5] Replace should returns => should return
Test plan:
Note that this patch only deals with POD lines or test descriptions.
So there is nothing to test, just read the patch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Patch amended by RM: The release notes should not be modified
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Resolves:
Use of uninitialized value $biblio_fields in scalar chop at authorities/detail.pl line 212.
Can't call method "authtypetext" on an undefined value at authorities/detail.pl line 216.
Can't call method "authtypecode" on an undefined value at authorities/detail.pl line 180.
NOTE: Some of these problems have actually been resolved now by bugs 18801
and 18811, but it is still better imo to have these checks.
Test plan:
[1] Verify unchanged behavior. Search for some authorities on authorities.pl
and click on the details of a record.
[2] Open an authorities detail page and change the authid in the URL to a
not existing number. Instead of an internal server error, you should see
a message like "The authority record you requested does not exist".
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The check is now <=-4 or >=5, but the framework uses 0 for Show all and
-5 for Hide all. (Note that sql installer scripts also use 8.)
When modifying an authority, the script also showed hidden fields when
filled, since it did not check the hidden field but only the tab field.
NOTE: The proposed solution restores consistency, but will remove hidden
fields from the MARC record.
Test plan:
[1] Set field 942a to Show all in an authority framework.
[2] Open a new record in this framework and verify that you see 942a.
[3] Edit an existing record in this framework and verify again.
[4] Set field 942a now to Hide all in this framework.
[5] Open a new record in this framework and verify that 942a is hidden.
[6] Edit an existing record in this framework and verify again.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We will need a few additional parameters for merge later on. This patch
puts the original parameters in a parameter hash.
For the same reason DelAuthority gets a parameter hash here.
Note: We remove the second parameter from the DelAuthority call in
authorities/authorities-home.pl here. It was not used and could have
presented problems in the future.
Test plan:
[1] Run t/db_dependent/AuthoritiesMarc.t.
[2] Run t/db_dependent/Authorities/Merge.t.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The commit b5ecefd485
Date: Mon Feb 3 18:46:00 2003 +0000
had a funny description:
Added function to check if a MARC subfield name is "koha-internal"
(instead of checking it for 'lib' and 'tag' everywhere); temporarily
added to Koha.pm
"Temporarily", since 2003, everything is relative, isn't it? :)
The thing is that GetMarcStructure returns hash like
field_200 => {
subfield_a => {
%attributes_of_subfield_a
},
%attributes_of_field_200
}
The attributes for field_200 can be 'repeatable', 'mandatory', 'tag', 'lib'.
We don't want to loop on these values when looping on subfields.
Since there are just { k => v } with v is a scalar (string), it's easier
to test if we are processing a subfield testing the reference.
At some places, we don't need to test that, we are looping on values
from MARC::Field->subfields which are always valid subfields.
Test plan:
1/ Edit items using the batch item mod tool
2/ display and edit items via the cataloguing module.
You should not see any changes between before and after the patch
applied.
Tech notes:
We need to check what we are processing when we loop on 'subfields' from
GetMarcStructure, not from MARC::Field->subfields.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Bug 6657 modified the way C4::Biblio::TransformHtmlToMarc operates in order to
solve an issue occuring during biblio record cataloguing. But this function is
also used by authorities cataloguing, and the code in this case is irrelevante.
This followup allows to distinguish for which kind of record
TransformHtmlToMarc is called: biblio/authority.
A bug appears in authority creation without this patch in some circunstances:
when authid is linked to 001 field.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Tested with a new authority record
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Bug 6657 modified the way C4::Biblio::TransformHtmlToMarc operates in order to
solve an issue occuring during biblio record cataloguing. But this function is
also used by authorities cataloguing, and the code in this case is irrelevante.
This followup allows to distinguish for which kind of record
TransformHtmlToMarc is called: biblio/authority.
A bug appears in authority creation without this patch in some circunstances:
when authid is linked to 001 field.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Tested with a new authority record
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
Test this patch with the previous one.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
These 2 subroutines are now not necessary anymore, we can use
Koha::Authority::Types to retrieve the authority types.
This patch won't be easy to test. Indeed, a lot of file are updated.
To test it I would suggest to focus on the merge authority
You should also confirm that the authtypecode and the authtypetext
values are correctly displayed when navigating in the authority module.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Test plan:
1/ update the Schema (misc/devel/update_dbix_class_files.pl)
2/ Translate templates for some languages (es-DE, de-DE for instance)
3/ Enable them in the pref (search for 'lang') for the staff interface
4/ Go on the item type admin page (admin/itemtypes.pl)
5/ Edit one
6/ Click on the 'translate for other languages' link
7/ You are now on the interface to translate the item type's description
in the languages you want. So translate some :)
8/ Go back on the item type list view (admin/itemtypes.pl)
9/ You should see the original description (non translated)
10/ Switch the language
11/ You should see the translated description in the correct language.
If the description is non translated, the original description is
displayed.
12/ On the different page where the item type is displayed, confirm that
the translated description appears.
Think further / Todo:
1/ Update all occurrences of the item type's description (DONE)
2/ Implement for authorised values
3/ Implement for syspref value (at least textarea)
4/ Implement for branch names
5/ Centralize all the translation on a single page in the admin area
...
N/ Implement a webservice to centralize all the translations and give
the ability to sync the item types/authorised values description with
the rest of the world (push and pull).
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The text for the marc field are truncated to 22 chars when displaying an
error on mandatory fields.
This limitation is useless and this patch removes it.
Test plan:
Create a mandatory subfield and set a long text (more than 22 chars)
edit or add an authority, click on save.
You should get the error displayed with the full text
Note that this patch modifies the same code for biblio.
Test plan is the same for biblio.
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch implements the use of Koha::FrameworkPlugin in Cataloguing,
Authorities, Acquisition, Serials and Tools.
The main change is architectural: see the commit message of the previous
patch. No changes in behavior are expected, but the support of new events
may provide additional functionality in the future. Some small bugs are
resolved along the way.
The change primarily focuses on the MARC and items editor in Cataloguing.
But the MARC editor for Authorities and the item editor in Acquisition,
Serials and Tools are touched too. This commit message gives some comments
per module.
NOTE FOR CATALOGUING:
A new plugin without popup (or other click event code) now shows the title
No popup when hovering over the tag editor image. The image alerts the
user on a plugin, the title tells about its status. The noclick property
allows for further style modifications in the template. Note that a
follow-up patch will clean up the old style plugins too with the same
effect.
Some additional code in cataloging.js makes it possible to clone subfields
with plugins (although only theoretically useful). The clones use the
same javascript functions but event.data contains an updated id.
This effectively resolves bug 13306. Note that if old plugins do not use
the javascript parameter for the id but the perl variable, cloning does
still operate on the wrong field (with and without this patch set).
In the absence of report 12176 in master, it is not yet necessary to modify
additem.tt. When it gets pushed, it should be an easy rebase.
New style item plugins will no longer need an extra parameter. (The code in
the FrameworkPlugin object actually takes care of that.)
NOTE FOR AUTHORITIES:
This patch also adds class name tag_editor to the buttonDot anchors. This
effectively makes the same tag editor image appear as in Cataloguing.
Futhermore it removes the button from the tab sequence if there is no click
event (really effective after conversion to the new style, since the old
style plugins contain empty onclicks and launchers).
Both small adjustments increase consistency between auth and bib edits.
NOTE FOR ACQUISITION:
In Acquisition two scripts use an item editor, but in a different way.
The scripts addorderiso2709 and neworderempty both rely on the routine
PrepareItemrecordDisplay in C4::Items, but neworderempty creates item
blocks dynamically via an ajax call to services/itemrecorddisplay.pl.
In order to make the dynamic item blocks work with plugins, some code
changes were needed in additem.js. (Normally the event binding is done
at document ready time; now it must be done later.)
At this moment the routine in Items.pm contains the html tags, and this
makes changes to the following templates not necessary for now:
* acqui/addorderiso2709.tt
* services/itemrecorddisplay.tt
Report 13397 has been opened to address moving the html to the templates.
NOTE FOR SERIALS:
Script serial-edit relies also on C4::Items (just as in Acquisition).
This makes changes to serials/serials-edit.tt not necessary for now.
NOTE FOR TOOLS:
The current code in tools/batchMod.pl allows the use of plugins for batch
modification of items. This patch just converts that code to use the new
object. Most item plugins however may not be very useful for operating on
multiple items at once.
PERFORMANCE:
I have benchmarked build_tabs in addbiblio to see how especially the
additional processing of the javascript in the FrameworkPlugin object
would impact performance. Testing default MARC21 framework with 8 plugins
gave the following figures:
- Old situation: 851 ms
- New situation: 942 ms (+10,7%)
- New situation after plugin cleanup: 881 ms (+3,4%)
Note also that adding lines for event binding is compensated by removing
lines for unused events. Page load should essentially be the same.
TEST PLAN:
Suggestion: If you also apply the next patch with the EXAMPLE plugin, you
can test with a rather harmless plugin (with popup) on various places :)
But your test should also include old style plugins, with[out] popups.
If you want to test a new plugin without popup, rename/remove Click$id
in the javascript code of the $builder definition (temporarily).
[1] Test Cataloguing:
- Add/Edit biblio. Try plugins with and without popup.
- Add/Edit items. (EXAMPLE can be used as an item plugin with popup.)
- Clone a subfield with plugin (use EXAMPLE): Verify that the plugin
works on both original and clone with the respective field values.
Is the value put back in the right field too?
[2] Test Authorities:
Edit an authority record. Try plugins with an without popup.
[3] Test Acquisition:
Set system preference AcqCreateItem to "placing an order".
Check the item editor in the following two places:
a- addorderiso2709: Open a basket, add an order from a staged file.
Select a file, click Add orders, and go to tab Item information.
b- neworderempty: Open a basket, add an order from a new empty record.
[4] Test Serials:
Check the item editor on serials-edit. Go to subscription detail.
Click Receive. Choose "Click to add item". (Note that this subscription
should create an item record when receiving this serial.)
[5] Test Tools:
Check the item editor for batch item modification. Enter a few valid
barcodes and press Continue to reach the item editor.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
http://bugs.koha-community.org/show_bug.cgi?id=11961
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This button lets you replace existing authorities using a Z39.50 search.
http://bugs.koha-community.org/show_bug.cgi?id=11961
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes HTML code from authorities.pl
To test:
1. Check no regressions on authority editor,
new/edit/save
2. Check new line on translation files, update
a language, look for 'Tag editor'
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Checked various features of the authority edtior:
- repeating subfields
- deleting subfields
- changing the order of subfields
- linking a subfield to an authorised value
- plugins
No regressions found.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In biblio (or authority) record editing or creation, Bug 3727 added
an empty value to combobox for subfields using itemtype authorized values,
which is mandatory and does not have a default value. This to avoid
selecting arbitrarily the first value of the combobox.
This patch extends this behavior to normal authorized values like CCODE,
COUNTRY ...
Also, when record already exists and has a defined value for the subfield
this value will be selected in combobox so there is no need for an empty
value.
Test plan :
- In a biblio framework, set a subfield mandatory and using itemtypes
authorised values
- Set a default value for this subfield
- Create a new record with the framework
=> You see the subfield with a combobox, the first empty value is selected
- Go to biblio framework and set a default value for the subfield
- Create a new record with the framework
=> You see the subfield with a combobox, the default value is selected
and there is no empty value
- Select an other value and save the record
- Edit this record
=> You see the subfield with a combobox, the saved value is selected and
there is no empty value
Perform same tests with a normal authorized values categorie (instead of
itemtypes).
Perform same tests with with authority creation/edition
Perform same tests with a normal authorized values categorie and authority
creation/edition
Signed-off-by: David Cook <dcook@prosentient.com.au>
Works as described.
Fridolyn: I had a lot of difficulty understanding your test plan,
especially since the second line should not be in the test plan
(since if there is a default value, no empty value should appear).
Perhaps it would be useful to use more whitespace to separate
steps and the things for which a tester should check.
Also, it might be useful to specify what testers should check for
before and after applying the patch, so that they're sure that the
behaviour has been corrected.
In any case, the patch works! Certainly a helpful addition.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
1) Adding a bibliographic record
Subfield is mandatory, no default value:
- adding record: no value is preselected, empty value exists
- editing record: saved value is shown, empty value exists
Subfield is mandatory, defined default value:
- adding record: default is preselected, no empty value
- editing record: saved value is shown, no empty value exists
Subfield is not mandatory, defined default value:
- adding record: default is preselected, empty value exists
- editing record: saved value is shown, emtpy value exists
Subfield is not mandatory, no default value:
- adding record: empty value is preselected
- editing record: saved value is shown, empty value exists
2) Adding an authority record
Repeating tests from above.
- Subfield is mandatory, no default value: OK
- Subfield is mandatory, defined default value: OK
- Subfield is not mandatory, defined default value: OK
- Subfield is not mandatory, no default value: OK
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch introduces a new Z39.50 interface for searching Z39.50
compliant databases for MARC authority records.
These databases aren't as common as their bibliographic equivalents,
but they're out there and very useful. I have included info at the
bottom of this messsage for sample authority databases you can try.
To test this patch:
1) Set up Z39.50 client targets for authority databases. (I've included
information at the bottom of this message for LibrariesAustralia's
test server for authorities as well as instructions on how to use
your Koha's z39.50 authority server as well. The Library of Congress
also has authority databases available (unsure if these are test or
prod), and you might have access to others through OCLC or RLIN. OCLC
provides login credentials for their test databases.
2) Go to the Authorities module
3) Click on the new "Z39.50 search button"
4) Select your authority search targets from the list.
5) Do a search for an authority you would like using either the "Raw"
input box or the more specific input boxes for names, subjects, subject
sub divisions, or titles. (I like searching Name (personal): Eric on
the LibrariesAustralia test DB.)
6) You should see a table listing the server, heading, authority type,
and two other columns (MARC and a nameless column). "Authority type"
is the type of authority it will become when imported in to Koha. In
the Eric example, "PERSO_NAME".
7) Click on "MARC" next to the results of interest to review the MARC
authority record.
8) When you're satisfied with a record, click on "Import".
9) The pop-up window will close and your original Koha window will
change to the "Adding authority Personal Name" screen (in the Eric
example).
10) All the relevant fields should be filled out for the record. Review
them and make any changes as necessary. (N.B. The 001 will be cleared
when saved, so if you have a use for the imported control number, move
it to the 010, 016, or 035 as appropriate. If you have a default value
for the 003, this will also likely be overwritten. Move it if necessary.
The 005 will also be updated when saved, so do not worry about that.)
11) When you're satisfied, click save.
12) Presto! You've imported your first authority record via Z39.50!
--
Here is the info for the LibrariesAustralia test Z39.50 authority
database:
Z39.50 server: LibrariesAustralia Authorities
Hostname: z3950-test.librariesaustralia.nla.gov.au
Port: 210
Database: AuthTraining
Userid: ANLEZ
Password: z39.50
Syntax: MARC21/USMARC
Encoding: utf8
-
The U.S.A. Library of Congress also provides Z39.50 access to its Name
and Subject Authorities (http://www.loc.gov/z3950/lcserver.html).
Name Authority:
Z39.50 server: Library of Congress Name Authority File
Hostname: lx2.loc.gov
Port: 210
Database: NAF
Syntax: MARC21/USMARC
Encoding: utf8
Subject Authority:
Z39.50 server: Library of Congress Subject Authority File
Hostname: lx2.loc.gov
Port: 210
Database: SAF
Syntax: MARC21/USMARC
Encoding: utf8
(N.B. Both of these databases also include title authorities.)
-
For testing purposes, you can also set up a Z39.50 client target,
which points at your own Koha instance's Z39.50 authority server.
To find the hostname, go to /etc/koha-conf.xml and find the value for
the <listen id="authorityserver"> element. Depending on your
configuration, this could be something like the following:
unix:/zebra/koha/var/run/zebradb/authoritysocket
(N.B. You might be using a different scheme than unix sockets...)
To find the database, scroll down to the bottom of koha-conf.xml until
you reach the <config> element. Within this, look for the value of the
element <authorityserver>. It should probably be "authorities".
To set up this Z39.50 client target in Koha...
Z39.50 server: my koha authorities
Hostname: unix:/zebra/koha/var/run/zebradb/authoritysocket
Port:
Database: authorities
Userid:
Password:
Syntax: MARC21/USMARC (or whichever flavour you need)
Encoding: utf8
Signed-off-by: Mason James <mtj@kohaaloha.com>
Bug 10096 [FOLLOW-UP] - Add a z39.50 interface for authority searching
This patch adds the "recordtype" column to the "z3950servers" table.
The value in this column (biblio or authority) then controls whether
the z3950 server shows up in a bibliographic search (through the
Acq and Cataloguing modules) or in an authority search (through
the Authorities module).
I also edited the z3950 management console to show this value
and allow users to edit it. The default value is "biblio", since
the vast majority of z3950 targets will be bibliographic. However,
there is an option to add/edit a z3950 target as a source of
authority records.
Test Plan:
1) Apply both patches
2) Run updatedatabase.pl (after setting your KOHA_CONF and PERL5
environmental variables)
3) Use the test plan from the 1st patch
N.B. Make sure that your Z39.50 client target has a Record Type
of Authority, otherwise it won't display when you're doing a
Z3950 search for authorities.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Bug 10096 [FOLLOW-UP] - fix tabs/whitespace errors to pass QA
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
New Authority system preference created UNIMARCAuthorityField100 with default value "afrey50 ba0".
AuthoritiesMarc.pm uses the system preference instead of label "afrey50 ba0".
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, all tests and QA script pass.
1) Check system preference is created correctly.
2) Change pref.
3) Catalog a new authority.
4) Change framework to make 100 show in frameworks or check in the
the database, that now 100 has the new defined value.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Passed-QA-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Passed-QA-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Although fields in the authority editor should support thesaurus
control, they should never be locked, as authority records commonly
refer to other records that may not be in use locally (and therefore
might not be in the authority file).
Test plan:
1) Make sure a 5xx field in one of your authority frameworks is
thesaurus-controlled.
2) Note that you cannot edit the field directly.
3) Apply patch.
4) Note that you can now edit the field irectly.
Signed-off-by: wajasu <matted-34813@mypacks.net>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
We didn't notice this one with jcamins when we fixed this bug.
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
When performing subject analysis, it is not uncommon to find that an
authority record you need does not exist. This commit adds a link in
the search results to enable the cataloger to create an authority on
the fly and have the heading populated by the new authority.
To test:
1. Use the auth finder plugin the cataloguing module to search for a
heading you do not have an authority record for.
2. Click the "Create new" link.
3. Fill in your authority and save it.
4. Note that the heading field was populated with the data you entered
in the authority record.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
1) Added a new authority using the plugin
2) Used an existing authority using the plugin
3) Created a new authority in the authority module
All worked nicely.
