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>
This patch improves how the page title and breadcrumbs for the patron
purchase suggestions page are generated by:
* removing references to a template variable that is not set by the
script
* using the patron-title.inc template include consistently
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
I don't know if it was a bug but at the OPAC, title is a required field
and not on the staff interface.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch:
- changes the GPL version from 2 to 3.
- uses the datatables.inc file
- removes the single pixel before and after the DT (modifying the sDom
value).
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a new tab to the patron side menu for purchase
suggestions. From this new tab, a librarian can view the patron's
existing purchase suggestios and also create new suggestions in the
name of that patron.
Test Plan:
1) Apply patch
2) Ensure the system preference 'suggestions' is enabled
3) View the details for a patron
4) Click the new 'Purchase suggestions' tab
5) Click the 'New purchase suggestion' button
6) Add the new purchase suggestions
7) You should now end up back at the borrower's purchase suggestions
8) Verify the new purchase suggestion was added
Signed-off-by: Corey Fuimaono <agent.075@gmail.com>
Step though the test plan. All OK.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.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>
"Print" label for search on the 106 field is not correct in UNIMARC
advanced search:
- 106 field can be used for non printed ressources (manuscript...)
- "Print" is ambiguous for translation tool, as it can be understood as
a verb or a noun.
The official label for 106 field is "Type of form". The offical label
for 106$a subfield is "Medium designator".
I think "Physical presentation" is the best way to describe the content
of 106$a in a user understandable label.
Test plan :
Check the "Print" label is replaced with "Physical presentation" in OPAC
(prog theme and Bootstrap theme) and Staff Advanced Search
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
OK for me. Make sense for UNIMARC users.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Amended patch: replace a tab with 4 spaces.
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>
