This patch makes Koha <-> Zebra use MARCXML for the serialization when
using DOM, and USMARC for GRS-1.
* The following functions are modified to set the Zebra record syntax
according to the current sysprefs and configuration:
- C4::Context->Zconn
- C4::Context-_new_Zconn
* A new function 'new_record_from_zebra' is introduced, which checks the
context we are in, and creates the MARC::Record object using the right
constructor.
The following packages get touched to make use of the new function:
- C4::Search
- C4::AuthoritiesMarc
and the same happens to the UI scripts that make use of them (both in
the OPAC and STAFF interfaces).
* Calls to the unsafe ZOOM::Record->render()[1] method are removed.
Due to this last change the code for building facets was rewritten. And
for performance on the facets creation I pushed higher version
dependencies for MARC::File::XML and MARC::Record (we rely on
MARC::Field->as_string).
* Calls to MARC::Record->new_from_xml and MARC::Record->new_from_usmarc
are wrapped with eval for catching problems [2].
* As of bug 3087, UNIMARC uses the 'unimarc' record syntax. this case is
correctly handled.
* As of bug 7818 misc/migration_tools/rebuild_zebra.pl behaves like:
- bib_index_mode (defaults to 'grs1' if not specified)
- auth_index_mode (defaults to 'dom')
here we do exactly the same.
To test:
- prove t/db_dependent/Search.t should pass.
- Searching should remain functional.
- Indexing and searching for a big record should work (that's what the
unit tests do).
- Test an index scan search (on the staff interface):
Search > More options > Check "Scan indexes".
- Enable 'itemBarcodeFallbackSearch' and try to circulate any word, it
shouldn't break.
- Searching for a biblio in a new subscription shouldn't break.
- Running bulkmarcimport.pl shouldn't break.
- And so on... for the rest of the .pl files.
[1] http://search.cpan.org/~mirk/Net-Z3950-ZOOM/lib/ZOOM.pod#render()
[2] a record that cannot be parsed by MARC::Record is simply skipped (bug 10684)
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.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>
By adding:
title=\"Tag editor\"
into the HTML generated in addbiblio, a tooltip displaying
'Tag editor' appears when the mouse is hovered over the
plugin icon.
Test Plan:
1) Log into Staff client
2) Click the 'Search the catalog' tab
3) Type something which will generate results
4) Click the title of a result
5) Click the 'Edit' button
6) Scroll down and click the 'Edit Record'
7) Look through the various tabs and notice that all the plugin
icons have no tooltip.
8) Apply the patch
9) Refresh the page
10) All the plugin icons should have the tooltip text of
'Tag editor'.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adds a title attribute. Works as described.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a problem where if a staff user has superlibrarian
permissions, but also has module-specific permissions, they are
prevent from editing item records that they should be allowed to.
To test:
[1] Turn on IndependentBranches.
[2] Register a superlibrarian staff user at branch A.
[3] Give that new account at least one other module-level
permission. This cannot be done through the user interface,
however, but can be done via SQL:
UPDATE borrowers SET flags = 3 WHERE userid = 'XXX';
[4] Log in as that new superlibrarian.
[5] Bring up the item details (catalogue/moredetail.pl) page for
an item at branch B. Note that there is no 'Edit Item' link.
[6] Similarly, try editing that item (cataloging/additem.pl). Note
that the edit form forbids you from touching the item.
[7] Finally, try editing that item using the Tools | Batch item
modification utility. Note that it doesn't allow you to do so.
[8] Apply the patch.
[9] Repeat steps 5 through 7. This time, the item actions should
be allowed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes QA script and test suite.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The method of checking the logged in user for superlibrarian privileges
is obtuse ( $userenv && $userenv->{flags} % 2 != 1 ) to say the least.
The codebase is littered with these lines, with no explanation given. It
would be much better if we had one subroutine that returned a boolean
value to tell us if the logged in user is a superlibrarian or not.
Test Plan:
1) Apply this patch
2) Verify superlibrarian behavior remains unchanged
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on second patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When QueryParser is off, the cataloging search is passing the incorrect
variable to SimpleSearch. I'm sure this is causing other issues, but
the one I have identified is that any searches with an "&" in them
return no results. This patch corrects the bug.
Test Plan:
1) Catalog a new record titled "Cats & Dogs"
2) Rebuild your zebra index so this record is indexed
3) Browse to cataloguing/addbooks.pl
4) Search for "Cats & Dogs"
5) Notice you get no results
6) Apply this patch
7) Repeat the search
8) Notice your result now shows up!
Signed-off-by: Heather Braum <hbraum@nekls.org>
Signed-off-by: Suzanne Fayle <sfayle@roseman.edu>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works as described, passes all tests and QA script.
Note: Because $query = $builtquery when the QueryParser is used,
this problem is only visible when UseQueryParser is set to "Don't try".
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a plugin for field 100 of UNIMARC
authorities.
To test on a UNIMARC site:
1) Apply the patch
2) Edit some authority framework, field 100
3) Link subfield 'a' to unimarc_field_100_authorities.pl
plugin, save
4) Edit or add auth record, click on '...' to bring plugin
5) Modify field 100a
6) Save record
Thanks to Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> for
converting Vitor's original patch to a Git patch and doing
some tidying.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Stephane Delaye <stephane.delaye@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Mandatory item fields are not indicated the same way in all places. This
patch corrects two places where required fields were shown in bold
rather than using the standard "required" class: When adding an order
from a staged file and when adding an item for a new issue of a serial.
This patch also normalizes the text input size on item entry forms: In
some places it was 50, others 67. I have changed the latter to 50.
Unrelated changes: Added $KohaDates formatting of date and time and
corrected capitalization on a heading on the add order from staged file
page.
It would be nice to be able to use the same method for displaying the
item form as we use on neworderentry.tt -- pulling in the form from a
separate include. However that system is designed for handling multiple
items and would need to be adapted for these cases.
To test, you must have a staged file from which to add an order. Open an
existing basket or create a new one and choose to add an order "From a
staged file." Choose a staged file from which to order. The item entry
form under the "Import all" heading should show required fields in red.
To test in serials: Begin the process for receiving an item from an
existing subscription. On the serials-edit page, find the "Click to add
item" links and click to open the item edit forms. There should be one
under the numbered issue and the supplemental issue forms. In both cases
the item edit screen should show the mandatory item fields in red.
Confirm that the cataloging add item form looks correct and works
correctly.
Revision: Left out the "required" note which should appear after each
required field.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When the only non-ascii characters in a new child record
are latin + diacritic in the range covered by Latin-1 they
are not being added to a new child record correctly encoded.
Explicitly setting the record's encodiing ensures that
they are interpreted correctly.
see "Unicode Bug" in perldoc perlunicode for background on
why these characters are special
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works well. No koha-qa errors.
Same test as before
1) with a record with diacritics in author/title,
2) press new child record, on new record 773adt
with mangled accents
3) Apply patch
4) Repeat 2, now good results
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Tested with a record containing umlauts in the title,
$t was empty before and umlauts in $a mangled.
After applying the patch fields are correctly filled and
diacritics display correctly.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
BiblioAutoLink was being called expecting an array to
be returned. The subroutine in fact returns a scalar
As the variables that the return was stored in, went
out of scope immediately. It is probably better to be
explicit that we are throwing the return away by not
going through the motions of storing it in a variable
To test:
[1] Add or save a bib record using the cataloging editor.
[2] Verify that no regressions have occurred
[3] (optional) If BiblioAddsAuthorities is on, verify that
relevant authority records are linked to from the bib.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- improve POD
- remove extraneous comments
- correct license statement in new files
- remove backticks in database update SQL
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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>
For some reason, _increment_barcode is called twice in succession in
cataloguing/additem.pl
Test Plan:
1) Enable autobarcode = incremental
2) Catalog an item, not the barcode
3) Apply this patch
4) Catalog another item, the barcode should be the next in line
as previously. No change should be noted.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Test Plan:
1) Apply the patch
2) Run updatedatabase.pl
3) Set WhenLostForgiveFine to Forgive & WhenLostChargeReplacementFee to Charge
4) Issue an item to a borrower, then set to lost from catalogue/moredetail.pl
5) Observe the replacement fee has been charged
6) Return the item
7) Observe the charged fee has been forgiven
8) Set WhenLostForgiveFine to Don't Forgive
9) Repeat 4-6
10) Observe the charged fee has not been forgiven
11) Set WhenLostChargeReplacementFee to Don't Charge
12) Repeat 4
13) Observe that a fee was not charged
Signed-off-by: Alex Hatley <alexh@cctexas.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds functionality to forgive overdue fine when an item is
set to lost status. Fines are forgiven only when the syspref
WhenLostForgiveFine is set to yes. Item can be set to lost status from:
- catalogue/moredetail.pl
- cataloguing/additem.pl
- tools/batchMod.pl
- misc/cronjobs/longoverdue.pl
Changed subroutine C4::Circulation::LostItem to forgive fines on the
item depending on the value of syspref WhenLostForgiveFine. This
routine is currently used to return an item and charge a replacement
cost.
Also added a new syspref in C4::Circulation::LostItem -
WhenLostChargeReplacementFee. The replacement fee will now be charged
only if this syspref is set to yes. The default value of the
WhenLostChargeReplacementFee is yes, meaning that current behavior
will not change during upgrade.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Alex Hatley <alexh@cctexas.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch in series.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described, no koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Copying the test plan from the bug report:
A.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 700 $a, $b, $f filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
fetch data from biblio rec. mentioned in 2)
4) see the punctuation in $a -- it will be wrong (no closing bracket)
B.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 700 $a, $b, $c, $f filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
fetch data from biblio rec. mentioned in 2)
4) see the punctuation in $a -- it will be wrong (dash instead of
semicolon between original $c and $f, no closing bracket)
C.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 702 $a, $b, $c filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
fetch data from biblio rec. mentioned in 2)
4) see the punctuation in $a -- it will be wrong (unnecessary semicolon
after original $c, n.b. lacking space).
D.
1) have $a active in one of the linking fields (like 461, 463, etc.).
2) have a biblio record with the field 712 $a, $b filled up
3) go to cataloguing -> field 4XX of your choice, use the plugin to
fetch data from biblio rec. mentioned in b)
4) see the punctuation in $a -- it will be wrong (unnecessary opening
bracket at the end).
Test plan, all tests and QA script pass.
Thx Bernardo for his testing and explanations!
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
[1] Turn UseQueryParser off.
[2] Ensure that your database has records in the reservoir. Performing
a Z39.50 search will do this.
[3] Perform a broad cataloging (i.e., cataloguing/addbooks.pl search).
Note that results are returned from the main catalog but that no
reservoir results are returned.
[4] Apply the patch.
[5] Perform the search again. This time, there should be both catalog
and reservoir results.
[7] Enable QueryParser. Perform the search again, and verify that the
catalog and reservoir results are the same.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patch works nicely, passes all tests, and the QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch changes the MARC21 007 plugin editor so that it uses
1 character instead of 4 characters for position 01.
TEST PLAN:
1) Create new record/edit an existing record
2) Using the tag editor for the 007 field, choose "Videorecording"
3) Click OK
4) Change the second character in the 007 from "c" to "d"
5) Open the tag editor again
6) Note that position 01 will still say "c - Videocartridge" rather
than "d - Videodisc".
7) Exit tag editor
8) Apply patch
9) Reload the page (Shift + Refresh is always useful)
10) Open the tag editor again
11) Note that position 01 will now say "d - Videodisc"
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Although previous/next browsing was added for searches in the OPAC
in 2011, the staff client has been without any sort of search browsing.
Until now. This patch is an all-singing, all-dancing, all-compatible
implementation of search browsing that will work across multiple
browser tabs and on any browser since IE7 (though the staff client
layout is broken on IE7).
To test:
1) Perform a search that will bring up multiple results.
2) View one of the results.
3) Use the Previous and Next links to browse along the search results.
4) Use the "Return to results" button to check that you end up at the
correct page of results, even if you page through more than 20
records.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Refactors Z3950Search.
Disable batch record counts for z3950 records.
Test plan:
Do various Z3950 searches on multiple targets from Cataloging and Acquisition.
Behavior should not have changed.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This follow-up moves all the MARC-specific functionality of Koha::Record
(now renamed to Koha::MetadataRecord) to a Koha::Util::MARC utility class.
To test, run relevant unit tests:
> prove t/Koha_MetadataRecord.t t/Koha_Util_MARC.t t/db_dependent/Koha_Authority.t
and optionally try to merge a record.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch refactors the merge record interface and code a little bit
in preparation for making it possible to merge authority records.
To test:
1) Apply patch.
2) Try merging two records:
a) Create a list.
b) Add two records you would like to (or be willing to) merge
to said list.
c) View said list.
d) Check the checkboxes next to the two records you added.
e) Click "Merge selected records."
f) Choose a merge reference.
g) Choose fields from each record that you want to keep.
h) Click "Merge."
3) Confirm that your merged record has the fields and subfields you
wanted.
4) Run the unit tests for the two files that were changed:
prove t/Koha_Record.t t/db_dependent/Koha_Authority.t
5) Sign off.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Move the XML and XSD data files so that access to them
(particularly the XML files) is not blocked by the Apache
configuration change introduced by the patch for bug 9812.
To test, after applying the patch.
[1] Open a MARC21 bibliographic record in the cataloging editor.
[2] Click on the plugin link for the 008 field. Verify that
that the form for all of the fixed field positions is displayed,
and verify that you can change the type of material.
[3] Repeat step 2 for the 006 field.
[4] Verify that there are no entries in the Apache error log that contain
client denied by server configuration: {...}/cataloguing/value_builder/marc21_field_008.xml
or
client denied by server configuration: {...}/cataloguing/value_builder/marc21_field_006.xml
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Also verified translation of those plugins still works correctly.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch corrects more places in Koha where the path to the "prog"
theme is hard-coded in templates, CSS, and scripts.
Staff client home page:
Paths to the Koha logo background image and the module image sprite have
been corrected. Inactive and hover states of the module links
(circulation, patrons, etc) should look correct.
addbiblio.pl:
An <img> tag is replaced with a text link and an
additional CSS class. CSS uses an image-replacement technique to display
the image as before.
To test, open a blank or existing bibliographic record for editing.
Confirm that the "tag editor" icon displays correctly in two cases: 1)
tags linked to plugin editors and 2) tags linked to authorities. Both
should look correct and work correctly.
System preferences:
The system preferences editor appends a "loading" image to system
preference submit buttons when they are clicked. This patch changes
ajax.js to insert a <span> styled with a background-image instead.
To test, open system preferences and modify any preference. Submit the
change and confirm that the "loading" image appears correctly.
Background jobs:
Any place in Koha where a background job is used displays a progress
bar. This patch corrects the path in CSS to the progress bar image. To
test, perform an action which triggers the display of a progress bar.
For instance, batch modification of items. Confirm that the progress bar
image displays correctly.
blue.css:
I don't know if this is still used by anyone, but a couple of image
paths in this CSS file have been corrected.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests, QA script and test plan.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This routine has been introduced by commit 2d90fb22d4.
The only call has been removed by commit 9eba7dc594.
So now, this routine is useless.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Changing the framework in the MARC editor immediately after duplicating
a bib record no longer clears the fields.
This patch changes the Changefwk Javascript function so that it passes
the "op" value and the "biblionumberdata" (as the biblionumber) from
addbiblio.pl back to itself, when submitting the form in order to
change the framework.
The reason we need to do this is because the form in addbiblio.tt
is hard-coded to always submit an "op" value of "addbiblio". Currently,
we need to have it hard-coded to "addbiblio", because all the magic
happens in addbiblio.pl when there is an "op" of "addbiblio". If we
always passed the "actual" "op" value, such as "duplicate", nothing
would ever happen when we clicked "save". It seems to me that this
is a flaw in the design of addbiblio.pl.
If we pass the "op" and "biblionumber" when changing frameworks, we're
able to tell addbiblio.pl that we're still wanting to "duplicate" this
"X" biblionumber. However, by having the form still hard-coded to
"addbiblio", when we hit save, the form will do the magic, check if
it's a duplicate, and save the record (or prompt for action if it
is a duplicate).
--
I also noticed that if you make changes to a record, then change
the framework before saving, your changes get cleared (since the
original record from the database is loaded when the page reloads).
It seems to me that this is a bug. Changing the framework should
change the layout while preserving the content. I think most users
would assume that when changing the framework.
This patch also introduces another hidden input into addbiblio.tt and
the Changefwk Javascript called "changed_framework". Basically, if
the Changefwk Javascript is run, it tells addbiblio.pl that the
framework is changed, and it uses the posted data from the form
(which we have been modifying) instead of reloading the record from
the database.
--
Test Plan:
A) Before Applying Patch:
To Show That Changing the Framework Erases All Fields When
Duplicating a Record:
1) Go to any bib record
2) Go to Edit > Edit as new (duplicate). You should see filled
in fields.
3) Change the framework to any other framework than the one
that is currently specified.
4) Note that every single field is now blank
To Show That Changing the Record then Changing the Framework
Ignores Changes, When Editing a Record
5) Go to any bib record
6) Go to Edit.
7) Change the title of the record to "I've changed the title".
8) Change the framework to any other framework than the one that is currently specified.
9) Look at the title. You'll notice it is the original title, and NOT "I've changed the title".
B) Apply the Patch
Also, clear your memcache and shift+refresh your screen. You don't want to use cached templates/javascript.
C) After Applying the Patch
Repeat Steps 1-3 and 5-8.
You should now notice that changing the framework when duplicating the item does not clear all the fields.
You should also notice that any changes you make prior to changing the framework will still exist after changing it.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In additem.pl, in the code that generates item form you find:
@values = $itemrecord->field($tag)->subfield($subtag) if ($itemrecord && defined($itemrecord->field($tag)->subfield($subtag)));
This patch adds the check of $itemrecord->field($tag) undef.
I did not found a way to test it because item tag is always defined
when editing an item, but it would be safer/prettier to add this check.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passed-QA-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When editing a biblio, the bug 7883 introduces the "save and continue
editing" feature. After saving, the page is loaded with the first
tab selected. This patch refresh the page with the same tab selected.
Test plan:
1/ Edit a biblio.
2/ Click on the 5th tab.
3/ Click on the "Save and continue editing" button.
4/ You are redirected on the same page with the same tab selected
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Several cataloging plugins make some simple AJAX GET calls via the YUI
AJAX feature. This code can be easily converted to jQuery.
To test, link each plugin to the relelvant field by editing your MARC
stucture. Confirm that functionality is unchanged.
For callnumber.pl and callnumber-KU.pl, test by linking to 952o.
callnumber.pl is triggered on blur of (when you focus on and click away
from) the 952o entry field. callnumber-KU.pl is triggered by clicking
the "..." link.
stocknumberam123.pl should be linked to 952i. If your data doesn't
already have information stored for inventory number, modify at least
one record to add one. The plugin is triggered on blur of the 952i
field. It should increment the highest value inventory number stored in
your system.
unimarc_field_010.pl is UNIMARC-specific, so I'm guessing about its
functionality. I tested it by linking the plugin to MARC21 field 020a.
The plugin is triggered on blur of the affected field (020a in my test).
You can confirm that the plugin returns valid data by using a tool like
Firebug to view the XHR response. Or if you're not using UNIMARC you can
hack the plugin to update a different field instead (line 57,
/^tag_210_subfield_c/ ). I tried "245_subfield_c" instead of
"210c_subfield_c." Nonsensical, but useful for testing.
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Tried the 3 MARC21 plugins. Did not try the Unimarc one, but it's exactly the same code change.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Enable IndependantBranches
2) Apply this patch
3) Run updatedatabase.pl
4) Verify that the system preference still functions correctly
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Patch reworked from Elliot Davis' original patch - but using bootstrap instead of YUI.
This patch adds the ability for catalogers to save and continue editing when adding new biblios.
To Test:
Select an existing item or create a new item in cataloging using your favorite framework.
Edit the bib
From the save menu in the dropdown, select the new option of "Save and continue editing"
If you are missing required fields you should still be prompted to fill them in before saving
Once all required fields are in place you should be allowed to save, and you will be redirected to tab 0.
The original patch claims to redirect to the original tab, but I never observed that behaviour from it - this patch merely takes what was in the original and makes it boostrap.
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Revised patch according to QA comments. No more dependent from bz 9780.
At present, merging records breaks the link order/record, except
if an item of the deleted record is used in the order.
This is a serious issue for libraries creating items on receipt.
This patch moves existing orders from deleted record to destination record.
It creates a new function Acquisitions::GetOrdersByBiblionumber,
that could be used by other patches later.
To test :
Check the problem :
1. Set syspref AcqCreateItem = Create an item when receiving an order
1. Create a basket with one order
2. Put the record used by this order in a list
3. Put an other record in the list
4. Merge the 2 records, keeping as a reference the record NOT used in the order
5. In the order, you will see for that order "Deleted bibliographic information..."
6. Apply the patch
7. Repeat steps 1-4
8. In the order, you will see the title/author of the kept record.
9. Set syspref AcqCreateItem = Create an item when placing an order
10. Repeat steps 1-4 (an item will be created)
11. In the oreder, you will see the title/author of the kept record
(it is already the case at present. the patch should not alter this behavior)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Test plan, test suite and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Test plan:
Same as previously.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Works. No errors.
Without patch and normal staff user, logged out
With patch, normal staff, valid output.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This plugin, for pseudo-authority-control of publisher information,
used YUI autocomplete to pull existing publisher data from the
biblioitems table. Despite its name it is not UNIMARC-specific.
It assumes publisher name data is saved in biblioitems.
This patch converts the autocomplete to jQueryUI. The search
script has been amended to return valid JSON. The template has
been modified to enable the jQueryUI autocomplete and to add
structure more consistent with other popups.
To test, link the publisher name field in your MARC structure to
the unimarc_field_210c_bis.pl plugin. Open a MARC record for
editing and click the "tag editor" link to launch the plugin.
Type the first few letters of a publisher which exists in your
database. You should get an autocomplete menu of publishers
which match your search. Select one and click the "choose"
button to fill the field in the MARC editor.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: work as described. No errors.
Test: link 260b to plugin. Edit record and search first letters
of present editors. Menú appears and can select and fill value.
Why plugin 210c_bis talk about field 225a?
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Plugin now works correctly for me, even when linked
to 260$b in a MARC21 installation. All tests and QA script
pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Someone at the library education in Oslo told me that it would be
better to have the default for 000/17 set to 1, instead of 2 as it
is today.
To reproduce:
- Run through the Web-installer in Norwegian and choose NORMARC as
the MARC dialect
- Go to Home > Cataloging > Add MARC record and start to add a new
record
- Click in the 000 field and it should be filled with:
" nam a22 2 4500"
- Reload the page, then open the value builder for 000 and click on OK
- 000 should get filled with the same string as above
To test:
- Apply the patch and repeat the steps from above. The default value
for 000 should now be:
" nam a22 1 4500"
(Don't be confused by the 1s and the 2s. A value of 1 in position 17
means "level 2", and a value of 2 means "level 1" - that is how it
is defined in the "standard":
1 = Nivå 2, iflg. Katalogiseringsregler
2 = Nivå 1, iflg. Katalogiseringsregler)
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Small changes. Didn't test in a NORMARC installaton, but
trusting Magnus with this and seeing no reason why it
shouldn't work.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch does several things:
- Set the default for 008/15-17 to "no " (yes, there is space at the end)
- Link from 008/15-17 in the value builder to NORMARC country codes
- Set the default for 008/35-37 to "nor" (by setting the
DefaultLanguageField008 syspref)
- Link from 008/35-37 in the value builder to NORMARC language codes
- Fix a missing <tr> around field 35-37
To reproduce:
- Run through the Web-installer in Norwegian and choose NORMARC as
the MARC flavour
- Go to Home > Cataloging > Add MARC record and add a new record
- Click in the field for 008. The default should look like:
130415t xxu||||| |||| 00| 0 eng d
^^^ ^^^
- Reload the page and open the value builder for 008. Problems:
- The text for 15-17 links to MARC21 country codes
- The default for 15-17 is xxu
- The text for 35-37 links to MARC21 language codes
- The default for 35-37 is eng
- If you choose e.g. "Monografier" in the top dropdown then click
on "OK" the window does not close
To test:
- Apply the patch and run through the Web-installer again, selecting
Norwegian and NORMARC
- Go to Home > Cataloging > Add MARC record and add a new record
- Click in the field for 008. The default should look like:
130415t no ||||| |||| 00| 0 nor d
^^^ ^^^
- Reload the page and open the value builder for 008.
- Check that...
- The default for 15-17 is "no " (with a space at the end)
- The link goes to NORMARC country codes
- The default for 35-37 is "nor"
- The link goes to NORMARC language codes
- Select something from the top dropdown and click "OK". Check that the
window closes and that the values that are entered into the 008 field
matches what you chose in the popup window.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Trusing Magnus is right, so testing for any regressions mainly, all good
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Only changes NORMARC specific plugin and system preferences
files. Changes all seem logical to me.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Searching for stdid: Standard ID, srchany: RAW (any) somehow did not work
anymore.
Probably my fault :) Note that these two fields are in Cataloging Z3950 search
and not in Acquisition.
Fixing encoding problems: When adding -utf flag for CGI in acqui/z3950 and
cataloging/z3950, the decoding statements in C4/Breeding, Z3950Search should be
removed.
Test plan:
Search in Cataloging with:
Standard ID: 9782358670043 on LOC
RAW (any): musee [add an accent aigu on first e] on LOC -- Add diacritic!!!
Search in Acquisition
Somewhere, does not matter, but use a diacritic.
A note: My git version still has a hard time with utf8. Need to upgrade to version 1.7.10 to resolve this..
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. No errors
Without patch z39.50 search for example Std ID OR musee gives no results,
with patch there are.
No problems in acq search.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch, passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This alternative patch modifies the script where the input markup is
built and adds an alternative configuration for textareas. This gives
the textareas explicit "cols" and "rows" attributes. I think this
solution is preferable to a style fix because it solves the bug while
eliminating some invalid markup (no "size" or "maxlength" attributes on
textareas, which are invalid without explicit dimensions).
To test, add a nice big chunk of text to an existing item's item field
like "Public note" (952$z), save, and edit again. The field should now
be displayed in a more comfortably-sized textarea.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
In current implementation (mostly commented out in this patch)
uses heuristic to guess which strings need decoding from utf-8
to binary representation and doesn't support utf-8 characters
in templates and has problems with utf-8 data from database.
With this changes, Koha perl code always uses utf-8 encoding
correctly. All incomming data from database is allready
correctly marked as utf-8, and decoding of utf8 is required
only from Zebra and XSLT transfers which don't set utf-8 flag
correctly.
For output, standard perl :encoding(utf8) handler is used
so it also removes various "wide character" warnings as side-effect.
Test scenario:
1. make sure that you have utf-8 characters in your biblio
records, patrons, categories etc.
2. try to search records on intranet and opac which contain
utf-8 characters
3. install language which has utf-8 characters, e.g. uk-UA
dpavlin@koha-dev:/srv/koha/misc/translator(bug_6554) $
PERL5LIB=/srv/koha/ perl translate install uk-UA
4. switch language to uk-UA and verify that templates
display correctly
5. test search and Z39.50 search and verify that caracters
are correct
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I followed the test plan, adding utf-8 characters to library names,
patron categories, titles, and authorized values. I tried the uk-UA
translation and everything looked good.
When performing Z39.50 searches for titles containing utf-8 characters I
got results which were still occasionally contaminated with dummy
characters [?] but I assume this is Z39.50's fault not the patch's.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Already signed, add mine.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch replace use of CGI::scroll_list() to show list of branches.
In two files, marc21_linking_section.pl and unimarc_field_4XX.pl,
the scrolling list is created but not used in the template file,
so the code is removed.
Also minor renaming/normalizing of variables.
To test:
1) Install with some branches, records and patrons
2.1) Select a record, click 'Place hold', select user,
there is a library pull-down next to 'Pickup at:',
list is ordered case sensitive
2.2) Go to Reports > Average loan time,
next to Library is a pull-down,
list without order
2.3) Go to Reports > Catalog by item type,
next to 'Select a library' is a pull-down,
list is ordered case sensitive
2.4) This is tricky, go to Reports home,
change last part of URL 'reports-home.pl' with
'manager.pl?report_name=issues_by_borrower_category'
(can't find a direct link), next to 'Select a library'
is a library pull-down,
list without order
2.5) Edit/Add a patron, on section 'Library management'
there is a library pull-down, case sensitive
2.6) OPAC, as logged user, make a suggestion or hold,
there is library pull-down, correct order
3) Apply the patch
4.1) Repeat 2.1), correctly ordered list
4.2) Repeat 2.2), correctly ordered list
4.3) Repeat 2.3), correctly ordered list
4.4) Repeat 2.4), correctly ordered list
4.5) This is a bit more work
There are 3 possible situations to test:
A) No branches, must show a message that are no
libraries defined
B) New patron, must show a correctly ordered
list of branches, current branch selected
C) Edit patron, must show a correctly ordered
list of branches, patron branch selected
4.6) Small changes on variable names, so retest 2.6)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
With the inclusion of this patch, all searches will (try) to use
QueryParser for handling queries for both the bibliographic and authority
databases if UseQueryParser is enabled. If QueryParser is unavailable,
UseQueryParser is disabled, or the search uses CCL indexes, the old
search code will be used.
To test:
1) Apply patch.
2) Run the unit test with `prove t/QueryParser.t`
3) Enable the UseQueryParser syspref.
4) Try searches that should return results in the following places:
* OPAC (simple search)
* OPAC (advanced search)
* OPAC (authorities)
* Staff client (header search)
* Staff client (advanced search)
* Staff client (cataloging search)
* Staff client (authorities)
* Staff client (importing a batch using a match point)
* Staff client (searching for an item for adding to a label)
* Staff client (acquisitions)
* Staff client (searching for a record to create a serial)
* ANYWHERE ELSE I HAVE FORGOTTEN
5) Disable the UseQueryParser syspref. Repeat at least some of the
searches you did above.
6) If all searches worked, sign off.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Elliott Davis <elliott@bywatersolions.com>
Searching still works as expected for variuos places.
QueryParser syspref seemed to be enabled by default
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Reviewing Bug 9649, this bug comes up.
This patch correctly sort frameworks by description.
To test:
1) Go to Cataloguing home, button 'New record' shows
unordered list of frameworks
2) Apply the patch
3) refresh, the list must be correctly sorted.
Revised to sort using uppercase.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
It's been a while since this bug is around. This normalization is only
used for UNIMARC and yields a fatal error when those variables are set
on (at least) MARC21 setups.
Regards
To+
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Amended patch: update comment
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Seems like simple omission when passing $pars hash to
Z3950Search function.
Test scenario:
1. select any Z39.50 search form and enter valid ISSN
2. verify that you don't get any results from remote servers
3. apply this patch and re-check that results are now availble
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Added a new system preference to set the UNIMARC field 100 default language.
The default value for that system preference is 'fre'.
Changed Biblio.pm to use the system preference:
- if the language is bad filled in the preferences it uses 'fre' as default value
- only replaces the language when the field 100 is empty
- if the language is filled with the plugin only replaces the positions 25-28 to 'y50'
Signed-off-by: Rolando Isodoro <rolando.isidoro@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When using fast cataloguing to create a biblio and item on the fly, workflow looses datas when a duplicate is detected.
This comes from the use of a mix of circborrowernumber and borrowernumber in forms.
This patch corrects by using always circborrowernumber in fast cataloguing workflow.
Also adds html and uri escape for barecode where necessery.
Test plan :
With duplicate :
- Go to a borrower circulation page
- Enter a non existing barcode
- Enter a due date
- Click on "Check Out"
=> a message says the barcode was not found
- Click on "Fast cataloguing"
=> The biblio edition page appears with fast cataloguing framework
- Fill mandatory fields by using an existing ISBN
- Click on "Save"
=> a yes/no message says "Duplicate record suspected"
(Choosing yes will brake fast caloguing workflow, in this case librarian should create an item and checkout again)
- Click on "No"
=> The item edition page appears with barcode already filled
- Fill mandatory datas
- Click on "Add item"
=> Borrower circulation page appears again, check that item has been checked out with the specified due date
You may test without duplicate
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Tested following the plan and by fast cataloging a non-duplicate.
All works as expected.
Signed-off-by: koha.aixmarseille <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
