MARC::Record 2.0.6+ enables the warnings pragma, and as a
consequence, started logging cases where a routine in
C4::Search was calling MARC::Field->subfield() with an undef
subfield label. This patch removes the log noise.
To test:
- Run prove -v t/db_dependent/Search.t
- There will be warnings about
"Use of uninitialized value $code_wanted in string" in MARC::Field.
- Apply the patch.
- Those warnings are gone.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Tests now pass
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Fix the supplier, shipment date, and library filters
on the invoice search. An invoice's library is
(in parallel with order search) defined as the library
of the staff member that approved the basket. Before this
patch, the code was referring to an aqorders.branchcode
column that doesn't exist.
This patch also improves the author, title, ISBN/EAN/ISSN,
publisher, and publication year filters to no longer require
exact matches; substring matches now suffice.
Finally, this patch considers biblio.copyrightdate in addition
to biblioitems.publicationyear for publication date searches, as
the MARC21 frameworks use the former column but not the latter.
This patch also fixes the current test cases for invoices
so that they pass and adds regression tests.
Test plan:
[1] Create two invoices for different vendors.
[2] Do an invoice search and filter on shipment
date. Verify that the expected invoice(s)
are returned.
[3] Do an invoice search and filter on branch
(of the staff member that approved the basket).
Verify that the expected invoice(s) are returned.
[4] Do an invoice search and filter on supplier.
Verify that the expected invoice(s) are returned.
[5] Do invoice searches on author, title, ISBN/EAN/ISSN,
publisher, and publication year and verify that the
results are as expected.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Patch passes all tests, test plan and QA script.
(Adding from Katrin notes early) I agree with
Possible improvements:
- Document the behaviour of the library search as there are
lots of branches all over acquisitions with different meaning.
- Add the shipment date to the results list table
- Change label ISBN/EAN/ISSN to not include EAN for MARC21
installations
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The default values for date fields is undef, so if a date field contains
an empty string, we should insert NULL in the DB, not 0000-00-00.
The format_date_in_iso routine should be only called if a date is
defined, is not equal to an empty string and does not match the iso
regex.
This patch fixes a bug where editing or creating a patron record
without setting the birth date results in 0000-00-00 rather than null
being set as the dateofbirth value.
Partial test plan:
1. Create a new patron. Leave dateofbirth empty.
2. Save the record.
3. Open the record for editing.
4. Save the record without making changes.
5. Koha gives no error.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Now when no date is given NULL is saved to the database.
Tested:
- Adding a patron without date of birth
- Editing the patron, entering a date of birth
- Editing the patron, deleting date of birth
All worked as expected.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Wrong usage of UNION instead of UNION ALL prevented the count to match
the expected value.
Steps to reproduce:
- Create an itemtype.
- Create some biblios setting the created itemtype at biblio level.
- Create some items setting the created itemtype on them.
- Try to delete the itemtype in Home > Administration > Item types, the
count is 1 and doesn't match the expected result.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Revert commit f88f11b4f8
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Before this patch, check-url-quick.pl fails with an error. After the
patch it runs correctly.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch updates the existing help files and
adds the missing offline circ help file.
To test:
* Visit all circ pages and check the manual links
* Visit the new offline circulation page and confirm text
and link are there (link will work after 10/25)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If koha-common is started when Zebra log files are owned by root
it will fail to start without any useful message (since Zebra can't
write errors in log files because it lacks permissions to do so).
This patch creates empty log files and ensure they have correct
permissions.
I can't pin-point why log files gets owned root, but I suspect it
has something to do with Zebra crashing and logrotate, but this is
just theory. We have seen this behaviour since koha 3.1 every
few months, and every time it happends we have root owned logs and
crashed Zebra so this patch will at least help sites which have
some kind of automatic koha-common start if it's not running.
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
1/ Edit a patron
2/ Add a restriction with a date (in any format other than iso)
3/ Note the date is not saved
4/ Apply patch
5/ Add restriction again, note it is saved
The problem is output_pref was being called with the wrong parameters
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Note: The issue in on the memberentry form only (not the restriction
form on the check out page).
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
Check that sysprefs.sql runs correctly.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When a record fails to decode during a search, Koha dies with an error.
Koha should ignore bad records and continue on ( and log the error ).
An example of a record that Zebra will happily ingest but which MARC::Record
doesn't like is one that contains a punctuation character in a tag label.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a regression test for Koha's ability
to gracefully handle records that Zebra will index but
which MARC::Record won't parse. In particular, MARC::File::USMARC
croaks on records that contain non-alphanumeric characters in the
tag name.
To test:
[1] After applying this test, run prove -v t/db_dependent/Search.t
The test script will die when it gets to the regression test.
[2] After applying the main patches that fix the bug, the test
script should pass.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
QueryParser was loading redundant search aliases, which in turn resulted
in certain queries involving two or more clauses joined by a Boolean
operator getting parsed in correctly.
To test:
[1] Enable QueryParser.
[2] Arrange your database so that some some bib records contain
the keyword 'history' while a smaller subset contain
both 'history' and 'earth'. (The exact words used don't
matter.)
[3] Run the following search from the OPAC global search bar:
kw:history && kw:earth
[4] Observe that the records that are returned include *all* bibs
in the database with the keyword 'history'. In other words, the
restriction that the records must also contain 'earth' is not
observed.
[5] Apply the patch and rerun the search.
[6] This time, the results that are returned should include only those
that contain both 'history' and 'earth'.
[7] Verify that prove -v t/QueryParser.t passes.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes test plans, all tests and QA script.
Also checked the db_dependent/Search.t tests.
Tried some other searches, all seems to be working correctly.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
I reproduce the bug and I confirm this patch fixes it.
Without the patch, kw:history && kw:earth, I got:
Search biblios OK 4 1 1+0 RPN @attrset Bib-1 @attr 4=6 @attr 1=1016 history
With the path, I get:
Search biblios OK 2 1 1+0 RPN @attrset Bib-1 @and @attr 4=6 @attr 1=1016 history @attr 4=6 @attr 1=1016 earth
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds regression tests to verify that
Boolean searches using QueryParser function correctly.
This patch also ensures that QP is correctly initalized
when Search.t is run.
To test:
[1] Apply this patch and the following patch.
[2] Verify that prove -v t/QueryParser.t works
[3] Verify that prove -v t/db_dependent/Search.t works
[4] (optional) instead of applying both patches at the same
time, apply only the regression test patch and run the
tests listed in steps 2 and 3. The following tests
should fail:
t/db_dependent/Search.t (Wstat: 512 Tests: 198 Failed: 2)
Failed tests: 42, 71
Non-zero exit status: 2
t/QueryParser.t (Wstat: 256 Tests: 28 Failed: 1)
Failed test: 12
Non-zero exit status: 1
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Editing partron data results in unintended adding of indefinite manual
restriction to it. Reason for it is hidden field add_debarment which
is wrongly initialized to 1 instead of 0. Also JavaScript code seems
to want to toggle checkbox, and since this field is hidden correct
approach would be to change its value to 1.
Test scenario:
1. edit patron data
2. verify that debarrment is wrongly added
3. remove debarrment
3. apply this patch
4. edit patron again
5. verify that debarrment wasn't added
6. intentionally add debarrment and verify that it's saved
7. add debarment, enter something in comment but press cancel
and verify that debarment isn't added
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This fixes this blocker, however, with or without the patch, the date
is not saved correctly. I will file a new bug for that
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a bug where if there are more than one table on the
same page that uses the DataTables column filter, applying a filter on
one table applied it to both.
Test plan:
1/ Go on serials/serials-search.pl?searched=1
2/ Filter on a column (e.g., title) on the open subscriptions
table.
3/ Switch to the closed subscriptions table. Observe that
that the table is *also* filtered by the criteria
set for the open subscriptions table.
4/ Apply the patch and reload the page.
5/ This time, applying a filter on one time should not affect
the other table.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In catalogue/results.tt, there is a small HTML error line 377 :
[% ELSE %]<option value"au,phr">Author</option>[% END %]
The = is missing
Test plan :
- In intranet, test go to advanced search
- Click on [More options]
- Enter a term, check "Scan indexes" and click on "Search"
- Look at HTML code of select "Indexed in"
=> option "Author" is correct : <option value="au,phr">Author</option>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Fixing some things the QA script pointed out this morning:
- whitespace
- variable declaration
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Check out at least 3 items, due dates should be today, sometime in
the past and one day after tomorrow.
- Edit the message options - activate DUE and PREDUE notices with
days in advance = 2
- Run the advance_notices.pl script with -v -c
Result: Only a PREDUE notice is generated
- Run the advance_notices.pl script with -v -c -m 2
Result: Only the PREDUE message is generated correctly.
- Run t/db_dependent/Circulation.t
- without first patch: all tests pass.
- with first patch: some tests will fail.
- Apply patch.
- Rerun script, now PREDUE and DUE notices should be
generated.
- Run t/db_dependent/Circulation.t again, all tests should pass.
Add more items with different due dates, rerun and check results.
Run t/Circulation.t to confirm all tests pass.
- Apply the patch
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Passes functional tests and automated tests.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Changes tests for GetUpcomingDueIssues:
days_in_advance should be inclusive:
2 should find items due in 2 days from now.
1 should find items due tomorrow.
0 should only find items due today.
Adds new tests for Bug 11218:
As the advance_notices.pl, the only script using GetUpcomingDueIssues
is not only used for PREDUE notices, but also for
DUE notices, we need to also select items due today.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
A JS error occurs on the pending reserves (holds to pull) page:
ReferenceError: CONFIG_EXCLUDE_ARTICLES_FROM_SORT is not defined
if(CONFIG_EXCLUDE_ARTICLES_FROM_SORT){
Test plan:
Apply the patch and verify the error does not appear anymore.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
A JS error occurs on the pending reserves (holds to pull) page:
ReferenceError: CONFIG_EXCLUDE_ARTICLES_FROM_SORT is not defined
if(CONFIG_EXCLUDE_ARTICLES_FROM_SORT){
Test plan:
Apply the patch and verify the error does not appear anymore.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
A "busc" param is cleared if the template name is not opac-.*detail.tt.
So if a user adds a biblio to a list, he cannot continue to browse
results.
Test plan:
- launch a search at the OPAC (opac-search.pl).
- click on a result and browse results (using previous/next links).
- a title attract your attention and you add it to a list
("Save to yours lists" link on the right).
- save the list.
- browse again results.
Signed-off-by: Joy Nelson <joy@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested according to test plan, also checked some other pages and actions
accessible from the detail page.
Passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
