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>
Galen found a case where the cookies array was not built flat. I add a
unit test for that (check the cookie array is flat) and also test the
cookies output of get_template_and_user so we are sure the &language=
parameter is correctly handled.
Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
- Tests in t/db_dependent/Auth.t pass
- Tested in intranet, OPAC logged in, OPAC logged out
* Adding a valid language code to the URL switches the language
as expected
* Adding an invalid language code causes no change
Nice feature!
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The current implementation didn't build the cookie array correctly,
yielding login problems in some scenarios.
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Passing language=<valid_language_code> as a parameter in any Koha's URL
can be used to set the desired language.
This patch touches
- C4::Templates
- C4::Auth
Adds a new method getlanguagecookie that does exactly that, for use in
get_template_and_user.
Also modifies getlanguage so it checks (a) if there's a 'language'
parameter in the CGI object and (b) checks if its valid and enabled for
the desired interface.
To test:
* Without the patch
- access any koha page
- add ?language=code to the end of the URL (change code for a valid language code
it needs to be installed using perl translate install code, and enabled either for
the staff or opac interface, depending where are you testing)
- Nothing happens with the language parameter
* With the patch
- access any koha page
- add ?language=code (the same as before) and hit enter
- the language should be changed to the one you chose
- if you browse through some links, you will see
koha 'remembers' the language you passed as a parameter
(i.e. the language cookie has been updated).
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Brendan <brendan@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Works very well. No errors.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
More comments on last patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Simplify an expression in the JavaScript
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes several improvements to the suggestions template:
- Improved breadcrumbs and page title.
- Fixed a JavaScript error which appeared when viewing or editing a
suggestion.
- Added an 'Edit' and a 'Delete' button to the suggestion detail page.
- Corrected capitalization.
To test:
- Perform various operations with suggestions management and
confirm that page titles and breadcrumbs are correct.
- View the detail page for an individual suggestion and confirm that
the edit and delete buttons work correctly.
- Confirm that there are no JavaScript errors when viewing or editing a
suggestion, in particular when changing Acquisition information
(quantity, currency, price).
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests, nice improvement.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Small patch to make koha-qa happy.
Fixes small POD error
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This is necessary because Bcrypt hashes are longer than MD5 hashes.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
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>
Test:
* SIP: Have an old user and create a new user
- use either tenet sip test or
C4/SIP/interactive_patron_check_password.pl to check old
userid/password
- do the same for the new user
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described
Test
1) using perl C4/SIP/interactive_patron_check_password.pl
can check current (short) and new (long) passwords
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test:
* LDAP:
- Turn on LDAP auth in koha-config.xml. Set "update" in your server config to 1
- Change user's password on LDAP
- Login to Koha using LDAP - Koha password should be updated, to check
- Turn off LDAP auth in koha-config.xml
- You should be ble to log in with the new password
I do not have a LDAP facility, so I cheated. I ran
perl -e 'use C4::Auth_with_ldap; C4::Auth_with_ldap::_do_changepassword("srdjan", 1000022259, "srdjan");'
and was able to change the password.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described.
Test
1) change <useldapserver> to 1
2) copy/paste sample <ldapserver> config from perldoc C4/Auth_with_ldap
3) using sample script was able to change password,
use (userid, borrowernumber, newpass) as arguments
4) checked with OPAC and in database
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
RM note: Digest::MD5 is used in C4::ImportExportFramework as part
of an unnecessary reimplementation of functionality supplied by
File::Temp. See bug 10991 for a proposal to remove it.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
What this patch aims to accomplish?
* All new passwords are stored as Bcrypt-hashes
* For password verification:
- If the user was created before this patch was applied then use
MD5 to hash the entered password <-- backwards compatibility
- If the user was created after this patch was applied then use
Bcrypt to hash the entered password
* Any password change made via the staff interface or the OPAC will
be automatically Bcrypt-hashed; this applies to old users whose
passwords were stored as MD5 hashes previously
Test plan:
1) Add new users and check whether their passwords are stored as
Bcrypt hashes or not.
2) To test that authentication works for both old as well as new
users:
a) Login as an existing user whose password is stored as a
MD5 hash
b) Login as an existing user whose password is stored as a
Bcrypt hash
3) In the staff interface, change the password of an existing user
whose password is stored as an MD5 hash
a) Check the new password is stored as a Bcrypt-hash in the database
b) Try to login with the new password
4) In the OPAC, verify that
a) Old user with old pass can change password, new format
b) New user with new pass can change password
c) Old and new user with self-updated pass can login
Whitespace cleanup was contributed by Bernardo Gonzalez Kriegel.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
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>
Test plan:
- add a fine for a patron
- verify the script does not delete this patron.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works, script do not delete a patron with fines.
No koha-qa errors with all patches applied
Test
1) Added a fine to a patron
2) run script
3) reports condition
Trying to delete patron 5... Failed to delete patron 5: patron has 10.00 in fines
4) Patron is not deleted
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Tested various combinations of options:
./delete_patrons.pl
Gives a helpful message about the use of the script.
./delete_patrons.pl -h
Outputs useful information about the use of the script
and its various options.
./delete_patrons.pl --category_code ST --library CPL
Gives the correct results in numbers and deletion was done
properly.
Also tested:
--expired_before
--not_borrowed_since
-v
Testing various conditions where a delete should not occur:
- Patron has checkouts
Patron is not in list of patrons to delete (x patrons to delete)
- Patron has fines
Patron is still in list of patrons to delete (x patrons to delete)
Checked deleted patrons had been moved to deletedborrowers.
Notes about possible enhancements:
- only print the success message 'x patrons deleted' when confirm
flag was set
- patrons with current checkouts are silently excluded from the number
of patrons to be deleted. Printing the number with current checkouts
might be helpful.
Changes made:
Fixed a small error in the documentation: expired_date is expired_before.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
[1] Patron deletion now happens atomically; if one part
of the process fails, the record isn't left in a
partially deleted state.
[2] The routine for handling lists properly during patron
deletion is now invoked.
[3] The script now prints an indication if it's run
without --confirm; otherwise, one might think that
patron records were actually being deleted.
[4] --verbose now actually does something.
Without --verbose, the script will print the dry-run
warning (if applicable), the number of patrons to be
deleted, and error messages.
With --verbose, the script will also print a line with
the borrowernumber of each patron to be deleted.
To test:
[1] Run the script with and without --verbose and compare
the, well, verbosity.
[2] Run the script without --confirm and note that the script
prints a message saying that it's running in dry-run mode.
[3] Use the script to try to delete one or more patrons that have
loans. Confirm that error messages are printed reporting
foreign constraints preventing the deletion. Also confirm that
no new rows are added to deletedborrowers for those patrons that
could not be completely deleted.
[4] Use the script to delete a patron that has a public list. Verify
that after the deletion, the public list still exists but now
has a null owner.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
[1] Use --library instead of --branchcode to be consistent
with other scripts and user-facing Koha terminology.
[2] Use --not_borrowed_since instead of --not_borrowered_since;
no need to expose typos in the API to the user.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This followup adds:
- execute flag (+x) for the cronjob script.
- replaces --dry-run with --confirm (according with existing scripts).
- changes output text (remove 'first person' style).
- updates the doc and simplifies the dates parameters.
- changes flags PrintError and RaiseError for the dbh in order to catch
something if an error occurs...
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch provides a cronjob script for deleting patrons.
It takes 3 options:
--not_borrowed_since
--expired_date
--category_code
See the perldoc misc/cronjobs/delete_patrons.pl.
Use the -v flag for a verbose mode.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10925 removes the last call to C4::Utils.
The module becomes useless and can be deleted.
Verify that t/db_dependent/Context.t still successfully passes.
git grep hashdump
git grep maxwidth
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Passes koha-qa.pl, no subs from the module are used anywhere
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently, if you launch the script
misc/load_testing/benchmark_staff.pl, it always displays
"Authentication successful" or continue to execute the script even if
nothing is done.
This patch checks if the url is right and if the authentication is
correctly done.
Test plan:
Suppose that a correct login/pwd is koha/koha
1/
perl misc/load_testing/benchmark_staff.pl --steps=1
--url=http://admin.koha.local/cgi-bin/koha/
--password="koha" --user="koha"
should produce:
Authentication successful
...
Step 1
...
2/
perl misc/load_testing/benchmark_staff.pl --steps=1
--url=http://admin.koha.local/cgi-bin/koha/
--password="KOHA" --user="KOHA"
should produce:
Authentication failure: bad login/password
3/
perl misc/load_testing/benchmark_staff.pl --steps=1
--url=http://admin.kobe.local/cgi-bin/koha/
--password="koha" --user="koha"
should produce:
Authentication failure:
500 Can't connect to admin.kobe.local:80 (Bad
hostname)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Works as described, detects bad url and user credentials.
No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and gives better error messages.
There are some warnings output when running the script before
and after applying the patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
For some reason the translator script was not picking up the see also
and used for/see from labels on the OPAC. This patch fixes the problem.
To test:
1) Apply patch.
2) Generate PO files.
3) Note that "see from" and "used for/see from" appear.
4) Sign off.
Signed-off-by: Nuño López Ansótegui <nunyo@masmedios.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely, thx for the fix.
Tested by updating the German po files, translating the
strings and installing the templates.
Verified strings show up in German in the authority
result list.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch builds on the patch for bug 10742 by ensuring
that when a search initiated from the staff interface simple
search returns results, if you click on the Z39.50 search
button, the search form is populated with the search string
without "kw,wrdl".
To test:
[1] Perform a search in the staff interface that will return
results.
[2] Click the Z39.50 search button.
[3] Observe that the search string appears in the title
field in the Z39.50 search form, but with a prefix of
"kw,wrdl".
[4] Apply the patch.
[5] Repeat steps 1-2. This time, the search string appears
without the index prefix. This will make the Z39.50 search
much more likely to work.
[6] Repeat steps 1-2, but with a search that does *not* return
any hits in the Koha database.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No koha-qa errors.
Fixes problem, but I think is better to remove
=back than to add nother =over 4, but I'm not
a POD expert
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This fixes a regression introduced by the patch for bug
9394 -- when printing a hold slip using the 'print and confirm'
button, the slip would contain only the text 'reserve not found',
not a full hold slip.
This patch also adds a regression test.
To test:
[1] Check in an item that would fill a hold. Use the 'print
and confirm button' to confirm the hold.
[2] The printout will only contain text to the effect of
'reserve not found'.
[3] Apply the patch.
[4] Repeat step 1. This time, a full hold slip should be printed.
[5] Verify that prove -v t/db_dependent/Reserves.t passes.
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>
Pass all tests, new and old, and QA script.
Verified wrong and corrected behaviour.
Note: Sometimes there will not be the message 'reserve not found'
showing up, but hold information for a different record. This happens
when there exists a reserve_id with the borrowernumber of the patron
in question in your database.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bug 10513 added two columns to table itemtypes,
but sample_itemtypes can't be loaded because
it relies on old structure.
This patch rewrites sample_itemtypes.sql, stating
explicitly columns, removing backticks and consolidates
all in one insertion.
To test:
1) On master with current DB structure, delete item types
2) try loading sample_itemtyes.sql
It fails with "ERROR 1136 (21S01) at line 1: Column count doesn't match value count at row 1"
3) apply patch
4) try again, this time it will load and itemtypes created
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
SQL change only.
Tested by running the web installer on an empty database.
All sample data loads without errors.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To reproduce:
1/ Edit your apache virtual host and set the DEBUG environment variable
(SetEnv DEBUG 1).
2/ Try to login with an ldap user
3/ You will be redirected to the 500 error page.
The Koha logs contains:
malformed header from script. Bad header=------------------------------: mainpage.pl
The hashdump routine directly prints to STDOUT (!) and breaks the
headers.
It appears Net::LDAP::?->dump does the same thing.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Maybe we can kill C4::Utils after getting rid of this
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
For a biblio with a lot of items, it is not easy to find the one you
want to edit.
Test plan:
Try to edit/delete item from the add item page.
Verify there is no regression on this page.
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Adding, editing and deleting items still works.
Search provides useful help for locating the correct items.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch improves the the toggles for displaying and hiding the hold
options div and the toggles for displaying the table of specific copies
to request. It also moves the copy table into the hold options div.
To test:
[1] Select a single title in the OPAC and click on the place hold
button.
[2] Click 'Show more options', and select a specific copy to request.
[3] Click 'Hide options'. Verify that the hold options, including the
copy table, are hidden.
[4] Click 'Show more options'. Verify that the specific copy radio
button is still selected and that the copy selected in step to is
selected.
[5] Enable DisplayMultiPlaceHold and select several titles to
request.
[6] Do steps 2, 3, and 4 on various titles on the request form. Verify
that toggling the options link for one title on the form affects
the visibility only for that title.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
While signing off I removed one <br /> tag and corrected a float in the
CSS. This helps keep the border between individual hold listings.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch changes the layout of the OPAC's place hold screen,
eliminating the table in favor of a more flexible, open display.
To test, place single and multiple holds under various conditions:
- Items which are not available to be place on hold
- With OpacHoldNotes on and off
- With OPACItemHolds on and off
- With OPACAllowHoldDateInFuture on and off
- With IndependentBranches on and off
- With JavaScript disabled
Test setting hold notes, holding specific copies, and setting hold start
dates. When setting a hold start date and hold expiration date, the two
datepickers should work together to prevent invalid date combinations
(dates after today, expiration dates which precede the start date).
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Configure an LDAP server and $KOHA_CONF, etc.
- Make sure ExtendedPatronAttributes is defined and that
there is no attribute defined that is specified to be
a unique ID.
- Try to log in using an account originating from the
LDAP directory.
- You will got a software error:
Can't use an undefined value as an ARRAY reference at
/home/koha/src/C4/Auth_with_ldap.pm line 183.
- Apply the patch.
- Try to log in again; this time it should work.
Signed-off-by: Nuño López Ansótegui <nunyo@masmedios.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch enhances the tags review page in the staff client by adding
DataTables sorting to the table of tags.
It also converts the tag list page (list.tt) to use the new DataTables
include introduced by Bug 10649.
To test, apply the patch and view the tags review page for various
categories: Pending, approved, rejected, all. The table should be
sortable by status, term, weight, and date. Sorting by date should work
correctly regardless of date format preference. Title sorting on the tag
list page should work correctly.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Amended patch: Replace tab with 4 spaces
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch deletes information for default
MARC21 auth framework on tags 68a and 68b.
Also added update for current installs.
RM note: The 68a and 68b fields were defined in an attempt to include
both MARC21 classification and MARC21 authority records in the same
default framework, but I don't think this has turned out to be useful,
as to my knowledge nobody tries to use MARC21 classification records
in Koha, and if one were to want to, a distinct record type (or at
least auth_type) would be a better way to do it.
To test with current authorities_normal_marc21.sql loaded
1) apply the patch
2) run updatedatabase
3) check on database that there are no more
references to tags 68a and 68b
To test for new installs
1) remove auth frameworks
2) load authorities_normal_marc21.sql
3) check that load without problem
4) check on database that there are no more
references to tags 68a and 68b
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Adds tests for CheckReserves with lookahead parameter.
Adds tests for AddReturn with regard to future reserve messages.
The following test cases are added, resulting in 8 new tests:
a) Add a reserve without date, CheckReserve should return it
b) Add a reserve with future date, CheckReserve should not return it
c) Add a reserve with future date, CheckReserve should return it if lookahead
is high enough
d) Check ResFound message of AddReturn for future hold
Test plan:
Run the test. No fails?
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Optionally add some branches and categories that may not exist.
Test plan:
Run the test with or without CPL branch or S (staff) category.
Verify that the test does not fail.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
After some thought, I had to reformulate what this pref does.
No code changes here.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Db rev for new pref ConfirmFutureHolds.
Test plan:
Run [your server]/cgi-bin/koha/installer/install.pl?step=3&op=updatestructure
Optionally, run a new install to test sysprefs.sql.
Or:
Edit sysprefs.sql, leave at least the last few lines including the new one.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
