This patch implements 2 suggestions on comment #3
- Prevents creation of a new user with same userid
of database user
- When checking password, if userid matches database user,
only check against pass on config file
To test:
1. Create a new user with same login as database user
any password different from real db user
2. Check that you can login on staff using this user/pass
and you are superlibrarian
3. Apply the patch
4. Login again using new pass, it must fail
5. Login again using db pass, you are now superuser,
but system does not warn you :( No problem, that's
for having one borrower with that login
6. Delete user with same login as db user
7. Try to create one again as in 1, system must return
an error of duplicate login!
8. Check for no regressions on user/pass authentication
Resubmited, has an error
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
This works nicely and as described.
Also editing the former 'superuser' will force you to
change the userid in order to save any other change.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Some improvements on t/db_dependent/Members.t and specifically regression
tests for bug 12226
Regards
To+
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To test:
- Add a new patron category
- After saving, the new patron category won't show up in the list
- Apply patch
- Try to add a new patron category again
- It should now save correctly and show up in the list of patron
categories.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This fixes a minor POD error detected, and also adds the Koha/ directory
to the regular test case so that the in-repo tests can find these
things.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This makes Koha::Cache behave better by default. It will use memcached
if available to do shared caching, if that's not available it will fall
back to in-memory caching. It also allows for a singleton accessor to
allow a single cache to be shared within a process.
* Added tests to confirm UTF8-cleanness.
* Added minor fixups to stop warnings.
Test plan:
* The t/Cache.t file runs successfully with and without the
MEMCACHED_SERVERS envvar set (and memcached running in the
environment.)
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we're passing an existing DBI database handle to
DBIC, and that handle doesn't have RaiseError set to true
by default, don't let DBIC override that -- for now.
Test plan: verify that the DB-dependent test suite passes.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
For now, just rely on the normal DBIx::Class cleanup handler;
otherwise, the following warning is displayed in logs:
(in cleanup) Can't locate object method "_preserve_foreign_dbh" via package "Koha::Storage" at .../Koha/Storage.pm
Using the default DBIC storage class also means that we
don't have to manually do things like set the SQL limit dialect;
meaning that we don't get the following warning message:
DBIx::Class::ResultSet::find(): Your storage class (Koha::Storage) does
not set sql_limit_dialect and you have not supplied an explicit
limit_dialect in your connection_info. DBIC will attempt to use the
GenericSubQ dialect, which works on most databases but can be (and
often is) painfully slow. Please file an RT ticket against
'Koha::Storage' . at /home/gmc/koha/C4/Members.pm line 840
Test plan: same as main patch
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Right now there is no connection between the database handles used by
C4::Context::dbh and Koha::Datbase/Schema. This makes it impossible to
use transactions in unit tests to temporarily modify the database to
test subroutines that take advantage of Koha::Database. This patch fixes
that issue.
Test Plan:
1) Apply this patch
2) prove -v t/db_dependent/ILSDI_Services.t and
prove -v t/db_dependent/Items.t and
prove -v t/db_dependent/Circulation_issue.t should
all start passing
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes changes in two cases to work around the fact that
Koha::Database and C4::Context were not using the same DBI database
handle.
To test:
[1] Run prove -v t/db_dependent/ILSDI_Services.t and
prove -v t/db_dependent/Items.t. Both tests
should fail.
[2] Apply the main patches and run step 1 again. This
time, both tests should pass.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If an item needs to be transferred to fill a hold, the hold will be
listed as 'Waiting to be pulled" while it is in transit.
Test Plan:
1) Place a hold for pickup at another library
2) Check in the item, confirm the hold transfer
3) View the holds for that record ( request.pl )
4) Note the priority is "In transit" and the status is 'Waiting to be
pulled".
5) Apply this patch
6) Reload the holds page
7) Note the status is now "Item being transferred to $branch"
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The column maxsuspensiondays was added in the datatable but not in the tests, which caused the failure of the tests
test plan: execute prove t/db_dependent/Circulation_Issuingrule.t
The command has to print:
t/db_dependent/Circulation_Issuingrule.t .. ok
All tests successful.
Files=1, Tests=9, 2 wallclock secs ( 0.03 usr 0.01 sys + 1.35 cusr 0.08 csys = 1.47 CPU)
Result: PASS
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Failure on test before patch, success after
No koha-qa errors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch is a follow-up for bug 11125, it fixes the bootstrap theme.
Test plan:
1) Remove 'sms' from message_transport_types table.
2) Go on OPAC "My messaging" tab => table columns are out of alignment with table heading.
3) Apply patch => table is correctly displayed.
Signed-off-by: Axelle Clarisse <koha.aixmarseille@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
With and without 'sms' existing the display of the table is now correct.
Template only change.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Many form elements on the add item page are giving a tabindex of "1" by
the script. This seems to make it impossible to tab through the add item
form fields onto the save buttons. I don't see a reason to set an
explicit tabindex of "1," so this patch removes it.
To test, apply the patch and open an item for editing. Try tabbing
through the add item form fields. It should be possible to tab through
the fields and onto the submit buttons at the bottom. Test again when
adding a new item.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The Classification Sources help file said the source was in the 942$2 but it's in the 952$2 and 94$2 so this patch fixes that.
To test:
* Go to Admin > Classification Sources
* Click Help
* Confirm the Help file is right now
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
String change, no errors.
Note: Perhaps change "Authorized Values ..." for "Authorized values ..."
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes the use of the 'when' smartmatch operator from
Serials.pm
Regards
To+
Sponsored-by: Universidad Nacional de Cordoba
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>
TransformKohaToMarc() function in C4/Biblio.pm iterates through it's
argument - which is a hashref - using 'each'. Perl is not guaranteed
to return hash keys in any particular order (not to mention that
in more recent perl versions, explicit hash key order randomization
is to be expected).
As a consequence:
1) For biblio records added via acquisition (order from a new/empty
record, order from a suggestion), freshly created MARC biblio records
doesn't always have 260 $b and 260 $c stored in the proper order
2) Holdings data exported for zebra indexing as 952 fields may have
subfields generated in more-or-less random order. While it probably (?)
does not affect zebra indexing/searching in any significant way,
end result is prone to be somehow ugly (which can be a potential
issue e.g. for people running Z39.50 server) and is not guaranteed
to be consistent; different records - or even different items in the
same record, can have 952 subfields generated in indiscriminate order.
This patch fixes abovementioned issues via introducting explicit
sorting (by subfiled code/letter) for subfield pairs before they
are added to the MARC record.
To test:
1/ Try to confirm and reproduce both issues (use perl 5.18.1 if possible
for more randomly ordered results).
2/ Apply patch.
3/ Redo the tests; ensure that both issues are now fixed and that there
are no apparent regressions of any kind (especially regarding to 952 fields
generated for zebra [re]indexing).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
So the first patron receives correct letters, but the followings received
all the previous ones AND his letters.
Eventually you end up with !n letters in message_queue where n = amount of patrons
receiving due messages as digest and having something due.
Eventually we got 4 000 000 ODUEDGST-letters of which 1 100 000 were sent to our patrons :)
This is madness!
Test plan:
0/ Delete the content of the message_queue table.
1/ Pick 3 patrons and set them to receive due messages as digest.
2/ Check 1 item out for 3 separate patrons and specify a due date today.
3/ Launch the advance_notices.pl script.
4/ Before this patch, you got 6 notices (1+2+3 [!n]). Now, you get 3 notices, 1 for each patron.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Problem exis.
Patch work as described following test plan.
No koha-qa errors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch ensures that only orders that have been placed (i.e.,
orders whose basket is closed) are counted in the OPACAcquisitionsDetails
display.
To test:
[1] Turn on OPACAcquisitionsDetails and set AcqCreateItem to 'ordering'.
[2] Create an order for a record, but do not close the basket.
[3] View the record in the OPAC. It should not display any order count.
[4] Close the bakset.
[5] View the record in the OPAC again. This time, it should display
the count of items on order.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds direct unit tests of the new biblionumber filter
for SearchOrders. It also moves the ordernumber filter test
to the rest of the SearchOrders tests.
To test:
[1] Verify that prove -v t/db_dependent/Acquisition.t passes.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a new system preference 'OPACAcquisitionDetail'.
If it is enabled, information about items on order will be displayed on
the OPAC detail page.
Test plan:
- switch on the OPACAcquisitionDetails pref.
- set the AcqCreateItems pref to 'receiving'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the "Holdings" tab contains the
line "X item are on order." (at the bottom of the table containing the
item list).
- receive the items.
- verify the number of items has decreased.
- set the AcqCreateItems pref to 'ordering'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the item list contains the items
with the "on order" status.
- receive the items.
- verify the received items no longer have the the "on order" status.
To test completely this feature, you should verify there is no
regression on the pref OpacMaxItemsToDisplay, OpacSeparateHoldings and
OpacSeparateHoldingsBranch.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Also removed some blank lines from the original patch and bumped up
the DBRev.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
this patch adds a negative-captcha feature to the purchase suggestions form
some info for the curious...
http://nedbatchelder.com/text/stopbots.htmlhttps://github.com/subwindow/negative-captchahttp://www.rubydoc.info/github/subwindow/negative-captcha/frames
to test this patch...
1/ apply patch
2/ enable 'suggestion' and 'AnonSuggestions' sysprefs
3/ attempt to add a 'purchase suggestion' in OPAC
adding the suggestion should succeed
4/ edit the koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-suggestions.tt file,
to reveal the hidden 'negcap' field
replace line 87 opac-suggestions.tt, from...
<li id="negcap" style="position: absolute; left: -2000px;">
to ...
<li id="negcap">
5/ attempt to add another suggestion, and populate the 'negcap' field
adding the suggestion should fail
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Amended patch: Remove the bug report number in the comment since git log
cans provide the same result.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Attempting to merge authorities results in the following error:
Uncaught SyntaxError: Unexpected token u authorities-home.pl:284
showMergingInProgress authorities-home.pl:284
(anonymous function) authorities-home.pl:297
o jquery.js:2
p.fireWith jquery.js:2
e.extend.ready jquery.js:2
c.addEventListener.B
This was the result of the upgrade of jquery-cookie by the patch
for bug 11369; newer versions of jquery-cookie changed the return of
$.cookie('foo') from null to undefined when the cookie is not present.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No test plan, no errors.
Test
1. search some authorities
2. click merge, on browser dev console pops reported error message
'Unexpected token u authorities-home.pl...'
No way to marge auths
3. with pach applied, merging works again
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
For libraries with large numbers of records, using a file of barcodes in
the inventory tool without selecting filters to limit the catalog
selection to compare against can result in an error of "could not read
headers" or a page timeout.
When you upload a file of barcodes, and do not specify any filters on
the rest of the form, it effectively runs GetItemsForInventory() such
that *every* item in the database is returned. On a large enough
database, this takes so long that the script times out.
The current documentation in the manual implies that if you upload a
file of barcodes, the *only* thing it does is set the date-last-seen
field. This is not entirely true; it also tries to compare the list of
scanned items to what is expected to be seen in the list of items.
The work-around for libraries with a large number of item records is to,
when uploading a file of barcodes, to also set the filters (e.g.,
library, shelving location, call number range, etc.) to
specify the range of items that the file of barcodes corresponds to.
This patch adds a warning when a librarian attempts to upload a
barcode list file for comparison without selecting any filters
to limit the catalog selection.
Test Plan:
1) Apply this patch
2) Browse to the inventory tool
3) Click the "Choose File" button, select a file
4) Click the "Submit" button
5) You should see a warning message
6) Click "Cancel"
7) Select one of more filters
8) Click the "Submit" button
9) This time the script should proceed without triggering the warning.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described following test plan.
No errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a line in opac-user.pl passing author info to opac-user.tt
Thanks to cait for helping me out and showing me how to solve this with half the amount of code.
Test plan:
* Reserve a book.
* Go to the opac and log in as the patron you reserved the book for.
* Apply the patch with change to opac-user.pl
* Revisit the opac and refresh it.
* See if author now shows up
Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Created a hold. Author is not shown n the public catalogue before
applying the patch, but it does show after applying the patch. Way
to go, Viktor!
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If you accept or reject a suggestion using the "Others..." option and
entering a reason manually, the text is not showing up in the Bootstrap
OPAC theme as it does in CCSR and prog. This patch corrects the problem.
This patch also adds a missing [% USE AuthorisedValues %] which would
cause errors if the template tried to display a custom suggestion status
as defined in the SUGGEST_STATUS authorized value category.
To test, accept or reject a suggestion and specify a custom reason. View
that suggestion in the Bootstrap OPAC and confirm that the custom reason
is displayed.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The patron summary page in the bootstrap OPAC does not show subtitle in
the list of checkouts, overdues, or holds. This patch corrects this.
To test, set your OPAC theme to bootstrap and log in to the OPAC as a
user who has items checked out, items overdue, and items on hold. At
least one of each of those should be a title which has a subtitle as
defined in Administration -> Keyword to MARC mapping. Subtitles should
appear correctly under the "Checked out," "Overdue," and "Holds" tabs.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Pushed to master by me in my role as OPAC module maintainer
Temporary fix into preferences.pl.
Bug 11944 should provide the real fix..
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Currently, slips cannot be printed in circulation, members, or the
self check out when using Chrome.
This patch adds a timer of 1ms which allows Chrome's custom code to
prevent "window.close" occuring before the user has dealt with the
print window.
This patch also allows admins to use the 'IntranetSlipPrinterJS'
system preference to override the slip printing code by centralizing
all the slip printing code in slip-print.inc, and including this JS
anywhere it's needed in the staff client.
I haven't used this include in the OPAC SCO but perhaps it would make
sense to do so as well (even if it isn't referred to in the syspref's
name).
_TEST PLAN_
1) Using Chrome on Windows (not sure if this is an issue on other OSes),
try to print a slip in the following locations:
Fines Tab -> Print button
koha-tmpl/intranet-tmpl/prog/en/modules/members/printfeercpt.tt:
Details tab -> Print button -> Print slip || Print quick slip
koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember-receipt.tt:
Details tab -> Print button -> Print summary
koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember-print.tt:
Fines tab -> Accounts tab -> Print (Manual invoice of $5 sundry)
koha-tmpl/intranet-tmpl/prog/en/modules/members/printinvoice.tt:
Checkout tab -> Print button
koha-tmpl/intranet-tmpl/prog/en/modules/circ/printslip.tt:
Finish button
koha-tmpl/opac-tmpl/bootstrap/en/modules/sco/printslip.tt
2) Note that each time you try to print, a new print page is created
but closed before you have a chance to print.
3) Apply the patch
4) Repeat Step 1
5) Note that the print page now doesn't close until after you've
chosen to print or cancel.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Using perl v5.18, the following is warned on updating/installing
templates:
Smartmatch is experimental at ./translate line 54.
Moreover, the following should exist with previous perl versions:
perlcritic xgettext
Subroutine prototypes used at line 29, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 44, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 60, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 72, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 89, column 1. See page 194 of PBP.
(Severity: 5)
Variable declared in conditional statement at line 105, column 13.
Declare variables outside of the condition. (Severity: 5)
Subroutine prototypes used at line 127, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 136, column 1. See page 194 of PBP.
(Severity: 5)
Variable declared in conditional statement at line 190, column 7.
Declare variables outside of the condition. (Severity: 5)
Subroutine prototypes used at line 237, column 1. See page 194 of PBP.
(Severity: 5)
Bareword file handle opened at line 238, column 5. See pages 202,204 of
PBP. (Severity: 5)
Two-argument "open" used at line 238, column 5. See page 207 of PBP.
(Severity: 5)
Subroutine prototypes used at line 277, column 1. See page 194 of PBP.
(Severity: 5)
Subroutine prototypes used at line 311, column 1. See page 194 of PBP.
(Severity: 5)
Bareword file handle opened at line 350, column 9. See pages 202,204 of
PBP. (Severity: 5)
Two-argument "open" used at line 350, column 9. See page 207 of PBP.
(Severity: 5)
Bareword file handle opened at line 353, column 5. See pages 202,204 of
PBP. (Severity: 5)
Bareword file handle opened at line 359, column 5. See pages 202,204 of
PBP. (Severity: 5)
Two-argument "open" used at line 359, column 5. See page 207 of PBP.
(Severity: 5)
perl -wc xgettext.pl
\1 better written as $1 at TmplTokenizer.pm line 474.
main::token_negligible_p() called too early to check prototype at
xgettext.pl line 52.
xgettext.pl syntax OK
Test plan:
Apply this patch and verify the warnings/errors does not appear anymore
and no regression is found on creating/updating/installing templates.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no koha-qa errros.
Tested with perl v5.18.2
No warnings, no problem detected on create/update/install i18n files
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 10833 introduced a variable loop but does not reset it every
iteration.
So the first patron receives correct letters, but the following ones
received all the previous ones as well as their own notices
Test plan:
0/ Delete the content of the message_queue table.
1/ Define advanced notices sent 2 days in advance for 2 patrons.
2/ Check 1 item out for each one and specify a due date today + 2 days.
3/ Launch the advance_notices.pl script.
4/ Before this patch, you got 3 notices. Now, you get 2 notices, 1 for
each patron.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work well, no errors.
Tested following test plan, printing on screen or saving into db,
3 messages before, 2 after (advance_notices.pl -v -n -m 2 -c)
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch ensures that a patron category that is present
in the (English) sample data is used for the ILS-DI tests,
avoiding a situation where one part of AddMember was trying
to access a patron category via DBIC but failed because
it was not visible to it yet.
Note that this will become easier once C4::Context->dbh
and DBIC are using the same base DBI database handles.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Conform former (implicit) behavior the handler now prints warnings by
default (via STDERR to logfile).
This can be adjusted by: $engine->print_warns(0);
Test plan:
Generate some error on a XSLT file (e.g. wrong path).
Check if your log contains the associated error(s)/warning(s).
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Modifies showmarc and opac-showmarc to use new XSLT handler.
Removes cardview.pl as obsolete script.
Modifies C4/Record.pm and a typo in the test Record.t.
Test plan:
[1] catalogue/showmarc: Go to Cataloging. Search. Click Card.
[2] opac-showmarc: Go to opac detail, MARC view.
Open URL for plain view in new tab.
Change URL: Change viewas=html to viewas=card
[3] Verify that there are no references in the codebase to cardview.pl
[4] C4/Record.pm: Run the Record.t test in db_dependent.
This test uses marc2modsxml, triggering the change.
Additional: export to MODS from opac-detail.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Views Ok. Test pass. No more cardview. No koha-qa errors
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Incorporate the new object into C4/XSLT module.
The handler object needed one adjustment to allow for passing URLs.
Removed the GetURI function; it is no longer needed.
Added some documentation lines.
Moved a file-level lexical upwards in the code for visibility.
Removed some tabs (on two lines).
Note: The handler could perhaps be moved up to the Context module, or
be saved in a global ('our') variable. But I would rather not do that
now, making testing not too complex at this moment.
Test plan:
Enable XSLT preferences for opac and intranet.
Check result and detail pages.
Check individual list display (virtual shelves).
Force an XSLT error by editing one of your xsl files. Check the
corresponding display.
Put an URL in one the XSLT prefs (could just be to your own server).
Check the display.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Running XSLTParse4Display in a loop showed no significant performance
change.
One pass cost me around 0.012 sec (except for the first pass).
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Results, detail, url and list view Ok
No koha-qa errors
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
Verify if XSLT_Handler.t passes.
You could also sabotage the test by removing one of the test xsl files.
Or you could 'repair' the bad xsl file (test02). Remove the second line
redefining the xsl variable.
In all those cases the unit test should fail now.. Discard your changes :)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test pass. No koha-qa errors.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In achieving the goals of umbrella report 6536 (Z3950 improvements), this
report adds a XSLT handler object to the Koha namespace.
A follow-up adds unit tests for this module.
This patch does not yet incorporate the new object into Z3950 search. So
it does not change any behavior and is therefore harder to test.
Test plan:
Run the unit tests of the follow-up patch on report 11826.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I tested the new module in two additional ways:
[1] Made a simple script (four lines as below) that ran a larger xml file
with 1500 records through a test XSLT file modifying the title.
my $eng= Koha::XSLT_Handler->new;
open my $fh1, '<', '_example_file';
my @xml= <$fh1>;
print $eng->transform( join('', @xml), '_example_xsl_file');
[2] Incorporated the object into my local changes of Breeding.pm (based on
older work, not ready for submittal now).
Ran transformation on Z3950 search results. Worked well :)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Test runs Ok. No koha-qa errors.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
As the way we need to reference Apache instance names has now changed
between 2.2 and 2.4, we need to try it out both ways to make sure we get
it right.
This also allows koha-create/koha-disable to try the .conf version of
the name if the first one doesn't work.
To test:
* Create an instance on an Apache 2.2 system with koha < 3.16
* Upgrade to 3.16 with this patch, saying 'yes' to the renaming question
** Make sure you don't see the warning: Warning: problem enabling $site
in Apache
* Do a 'service apache2 restart'
* Make sure you can still access the instance
* Make sure that /etc/apache2/sites-enabled/instance.conf exists as a link
to /etc/apache2/sites-available/instance.conf
* Check that koha-create and koha-remove behave like you'd expect.
Note:
* If you need to make debconf forget that it asked you the question
about renaming so that it'll do it again, then run:
echo "unregister koha-common/rename-apache-vhost-files" | sudo debconf-communicate koha-common
* 'debconf-show koha-common' will show you the current debconf
configuration.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Changed the syspref.sql file to remove one of the doubled
up UNIMARCAuthrityField100 that slipped in with an earlier
patch on this bug.
Passes all tests and QA script, also t/db_dependent/Circulation_issue.t
Tested with items that had
- no notforloan value set
- notforloan value not used in updateNotforLoanStatusOnCheckin
- the notforloan value defined in UpdateNotForLoanStatusOnCheckin
Also verified it works the same, when the item was checked out or
not checked out on return.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Some libraries would like to streamline the cataloging process my
automatically updating notforloan values on checkin. For example, an
item is set to notforloan of -1 ( ordered ). The item, is received,
processed, and checked in for the first time before being shelved.
The checkin automatically changes the nfl value from -1 to 0. The
same workflow could be used for damaged items as well.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Set the new system preference UpdateNotForLoanStatusOnCheckin
to the following:
-1: 0
0: 1
4) Create an item, set its notforloan value to -1
5) Check in the item, note its not for loan value is now 0
6) Check in the item again, note its not for loan value is now 1
7) Check in the item again, note its not for loan value reamins 1
Signed-off-by: Havilah Lyon <havilah@aflibrary.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Testing notes on last patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
