The current code for facets doesn't pull strip ending punctuation from facets
This causes duplicate facets for terms that should be combined
Sometimes series can have different punctuation depending on the field they are in
Author initials punctuation should be preserved
To test:
1 - Do search and pull up some records
2 - Edit some of the records to have authors like:
Date, C.J.
Date, C.j.
Date, C.J .
3 - Edit the records to have some series statments like:
830 $aDate, C.J. ;$v5
830 $aDate, C.J. ; $v5
830 $aDate, C.J.; $v5
4 - Add some 490s to the record with first indicator 1 and series like:
You wouldn't want to--
You wouldn't want to
You wouldn't want to..
5 - Search again and note you have 3 facets each for author and series
6 - Apply patch
7 - Repeat
8 - Now you get 2 facets for author, period not removed when following Upper case immediately, is otherwise
9 - Now you should have a single series facet
10 - Switch search engine to ES (index before applying patch)
11 - Note facets are separate again
12 - Reset mappings and reindex
perl misc/search_tools/rebuild_elasticsearch -v -r
13 - Repeat search, facets combined as above
Signed-off-by: Sarah Cornell <sbcornell@cityofportsmouth.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This takes care of more occurences of staff client and changes it to
staff interface, including in code comments.
To test:
- I think in this case careful code review is what we look for.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch
* sets one check for reserves and another for old_reserves in
atomic update
* Adds a message below the checkbox and adds detail when a hold is non
priority
* Fixes issue when there are more than one hold, but the first is non
priority
* Adds test case for this last scenario
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch implements necesary code to implement non priority feature
To test:
1) Apply all patches.
2) Run updatedatabase.
3) Checkout a specific item for patron1.
4) Place a hold on the same item for patron2 (do not check non priority
hold checkbox).
5) Try to renew the item for patron1.
CHECK => in checkouts table, there is a message that the item could not
be renewed because there was a hold.
6) Cleanup all checkouts and holds.
7) repeat steps 3 to 5, but this time check the non priority checkbox.
SUCCESS => item was renewed
8) prove t/db_dependent/Holds.t
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries would like to be able to cancel a hold with the option to
specify a reason. Providing a reason would generate an email to that
patron.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Create new AV category "HOLD_CANCELLATION", add some cancelation reasons
5) Add new Holds module notice "HOLD_CANCELLATION", add an email version.
A quick test version would be "Reason: <<reserves.cancellation_reason>>"
--
[% USE AuthorisedValues %]
Reason: [% AuthorisedValues.GetByCode( 'CANCELLATION_REASON', hold.cancellation_reason, 'IS_OPAC' ) %]
[% IF hold.cancellation_reason == "MY_AV_VALUE" %]
IF perhaps you'd like to have a much longer explanation than just the
one sentence in the AV description, you can use IF blocks using Template
Toolkit markup!
[% END %]
--
6) Place a hold for a patron
7) On request.pl, select the 'del' option for the hold
8) Select a cancellation reason and choose "Update hold(s)"
9) Note a new message has been queue for the patron with the cancelation reason
11) Test again from circulation.pl
12) Test again from moremember.pl
10) Cancel a hold with no reason, note no email is generated
11) Delete your authorised values, not the feature is disabled
12) Reinstate the authorised values, but delete the notice,
you should now be able to cancel a hold with a reason,
but no email will be generated
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Rebecca Coert <rcoert@arlingtonva.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It adds a new localization directory that could
host a custom SQL file for each language,
xx-YY/custom.sql
This will be the last file to be loaded at
install time, it can be used to set any difference
from default values.
It can't be deselected at install time.
Moved corresponding files for de-DE, it-IT,
nb-NO and completed es-ES
To test:
1) Apply the patch
2) Install es-ES/de-DE/it-IT/nb-NO translation (any lang)
( cd misc/translation; ./translate install es-ES )
3) Do a clean install using es-ES
4) After all files have been loaded check:
* A new section labeled "Localization data added"
with one file, custom.sql
* Inspect the value of FrameworksLoaded syspref,
last entry must be custom.sql
5) Remove/rename the file or localization dir and
repeat 3/4, install must proceed normally
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The 'summary' field in the patron information request specifies if detail information should be send for holds,
overdues, fines, etc. The field is 10 characters in length (0-9). However, the SIP2 spec only defines indexes 0
though 5, leave 6 though 9 undefined. Some ILSs specify behavior for these undefined indexes. Apparently the
7th field is often used to request 'Fees', as opposed to 'Fines' in some ILS. Some software that integrate via
SIP try both the 5th and 7th indexes to ensure they get all fines and fees.
The problem is that Koha's SIP server crashes if any 'summary' index beyond 5 is flagged. We should simply
ignore flags beyond 5 and act as if no flags were sent.
Test Plan:
1) Enable SIP for your instance
2) Send a patron information request with a summary flag in any index beyond 5.
i.e.: 6300120200617 124846 Y AOMIDAY|AA21030050054321
3) Note the SIP server just closes the connection without a response
4) Apply this patch
5) Restart the SIP server
6) Send the same request
7) Note you get back the patron information response!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jeff Gaines <jgaine@arlingtonva.us>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is just a guess! One of our tests is failing since today and we
don't modify anything in this area.
My guess is that the service is now returning the normalized version of
the ISBN
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Inside of ItemsAnyAvailableAndNotRestricted was no effect from main set
of smart rules (per record and other limits): i.e. call to
"CanItemBeReserved" was absent totally.
Because of this there was a bug: for example none of two items were
allowed to be held when first was allowed by one smart rule, BUT on loan,
and second was disallowed by another smart rule (for example,
0 "Holds per record"),
i.e. in this case both items unavailable: so on-shelf holds setting
"allow hold if all unavailable" should allow to hold first one, and not
the second one. But it was that both wasn't allowed to be held.
Solution: call to sub "CanItemBeReserved" added so it checked for
"...->{status} ne 'OK'" so now if item restricted by smart rule it also
accounted as "unavailable" and "AnyAvailavble" not counts it.
How to reproduce:
1. Add 2 smart rules (/cgi-bin/koha/admin/smart-rules.pl) with "on shelf
holds": "if all unavailable" for all rules, no "item level holds", and
set "holds per record" to 2 for "books" and "0" for "computer files".
2. Create only 2 items for one biblio, but different types, "book"
and "computer file". For example in misc4dev env:
/cgi-bin/koha/cataloguing/additem.pl?biblionumber=1#additem
3. Check out that item of type "book" to some person, for example,
in misc4dev:
/cgi-bin/koha/circ/circulation.pl?borrowernumber=2&barcode=3999900000001
4. Open reserve/request, for example, for item 1 and patron 1 in misc4dev
env (/cgi-bin/koha/reserve/request.pl?biblionumber=1&borrowernumber=1)
5. It does not allow to hold, both red crossed, but computer file says
"Exceeded max holds per record" because of "0" limit set on step 1.
6. Apply the patch.
7. Reload page on step 5 and see that "book" will be available for hold,
but "computer file" still will be red-crossed "Exceeded max holds
per record", now that's correct because both items unavailable:
one because on load, another because of "0" limit for computer files.
8. Check-in book from step 3 so it will be returned to the library,
9. Reload page on step 5 and see that again no any holds available,
but it's now also correct: "book" now returned but "on shelf holds"
set to "if all unavailable".
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add cut-off shortcut (return from inside the loop) when first
"Any Available And Not Restricted" item found, because one is
enough for "Any".
Testing: no change visible for code behavior/results,
it is just faster because won't loop over the whole set.
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Naming mistake came because this sub is used to detect if anything
available for hold, but it used in "if ANY UNAVAILABLE rule", so actually
results of this sub negated (see below "return" in the code).
In details:
when previous refactor was done, name for subroutine was chosen
wrongly in "opposite" direction from what it actually does:
it was named "ItemsAnyAvailableForHold", but this subroutine gave
truth (1) if at least one of the items available on shelf, not lost,
not on loan, not held, and not restricted by smart rules and damaged
status. So, if this sub says that item is still "available", this
actually PREVENTS item from hold in parent sub (see negated return):
sub IsAvailableForItemLevelRequest {
...
my $any_available = ItemsAnyAvailableAndNotRestricted...
return $any_available ? 0 : 1;
# ^^^ if any available and not restricted - we don't allow
# on-shelf holds
...
I.e. like it named now: "ItemsAnyAvailableAndNotRestricted".
Small aside fix: white space for '&&' inside brackets added to join
operation by priority visually.
Testing plan not needed: all places where sub used it just renamed.
More: all this places/code was introduced in one older commit so there
is also no overlaps or other calls/uses for this subroutine.
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
After discussion with Martin we decided that it could be the correct way
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It was not used
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This code was duplicated and we are going to need it.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Remove duplicated logic for searching circulation rules.
This can be replaced with get_effective_rules().
To test:
1. prove t/db_dependent/Circulation/GetHardDueDate.t
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Koha::ActionLogs->search must be used instead.
There is no call to this subroutine in our code, it should be removed.
Test plan:
Make sure the 3 test files still return green and that there is no more
occurrences of GetLogs in the codebase.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Go to Circulation->Transfer
2 - Note your signed in branch
3 - Find an item from your branch and create a transfer to branch B
4 - Confirm the item is marked as held at your current branch and is being transferred to B
5 - Find an item from a third branch, branch C
6 - Transfer that item to brnach B
7 - Confirm the item is held at your current branch and is being transferred to B
8 - prove -v t/db_dependent/Circulation.t
9 - prove -v t/db_dependent/Koha/Items.t
10 - prove -v t/db_dependent/RotatingCollections.t
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 26078: (follow-up) used validTransfer instead of checking WrongTransfer message
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
- Have 2+ branches
- Set your default return policy to Item returns to issuing library
- Find an item with holding branch of Branch A
- Set your library to Branch B
- Check item in
- Koha generates a transfer to Branch A. In doing so, it sets the item holding branch to Branch B
- Set your library to Branch A
- Check item in
- Koha generate a transfer to Branch B. In doing so, it sets the item holding branch to Branch A
- Set you library to Branch A
- Check the item in
. . . Repeat indefinitely.
Apply patch
Repeat
No more loop
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves subroutine 'GetDailyQuote' to new
Koha::Quote object and adjusts tests.
To test:
1. Set 'QuoteOfTheDay' as 'enable'
2. Check that quote is displayed on OPAC mainpage
Prove t/db_dependent/Koha/GetDailyQuote.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should support the SIP2 "circulation status" value 12, "lost".
Test Plan:
1) Apply this patch
2) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Now that we have return claims in Koha, we should support the SIP2
"circulation status" value 11, "claimed returned".
Test Plan:
1) Apply this patch
2) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We should support the SIP2 "circulation status" value 10, "in transit
between library locations"
Test Plan:
1) Apply this patch
2) prove t/db_dependent/SIP/Transaction.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The original code assumed every codepath should be trated as a
successful check-in. Such is not the case and the regression tests
verify that the code acknowledges this.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Illrequests.t
=> FAIL: Tests fail
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is only a perltidy of _check_max_qty to remove some space
inconsistencies, like:
if( $max_checkouts_allowed eq '' ){ return;}
if ( $checkout_count - $onsite_checkout_count >= $max_checkouts_allowed ) {
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We only need to prefetch items if CircControl is set to ItemHomeLibrary
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same as before but for patron_maxissueqty
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Making use of Koha::Checkouts make the code much more readable here.
It fixes 2 flaws:
* $type was not quote escaped
* the effective itemtype was not used which could lead to wrong
calculation (for instance item-level_itypes is set but the item does
not have the itype defined)
However there is something to note, we are going to make things a bit
less effective as we are now fetching the items to get their effective
itemtype (vs a SUM done at DB level)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The different calls to _check_max_qty can be improved to highlight what
is really changing between each of them.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch modifies the code for parsing MARC framework configurations
so that the placeholder "<<YY>>" translates to a two-year date.
To test, apply the patch and modify a framework to include placeholders.
For example, in MARC21:
- Administration -> MARC structure -> 952 -> Edit subfields -> d
- Expand "Advanced constraints" and add a default value:
<<YYYY>> <<YY>> <<MM>> <<DD>> <<USER>>
- Save your configuration and go to Cataloging.
- Go to the add/edit items page for a record which uses the framework
you edited.
- In the "Add item" form, in the "Date aquired" field, you should see
the correct values. For example: '2019 19 12 03 Leonard'
Perform the same test when adding an item during the Acquisitions
process (depending on your AcqCreateItem setting).
Note that acqui/neworderempty.pl has been modified because the
placeholder-replacement code is repeated there, but I couldn't discover
how to test it (if it is used at all?)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch replaces all calls to RefundLostItemFeeRules with
Koha::CirculationRules->get_lostreturn_policy and removes the module it
makes redundant.
Test plan
1/ Confirm that there are no longer any uses of RefundLostItemFeeRules
in the codebase
2/ Confirm circulation tests still all pass
3/ Confirm you can still set and unset the lost return rules
4/ Signoff
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When importing records from a SRU server, the diacritics have bad encoding.
I reproduce with BNF server so it may be a UNIMARC issue.
Tests show that difference between Z39.50 server and SRU is that leader contains 'a' at postion 9.
Looking at MARC::Record->encoding() shows that encoding depends on leader even for UNIMARC.
So this patch adds a call to MARC::Record->encoding('UTF-8') in case of a SRU server in C4::Breeding.
Same use exists in Koha::MetadataRecord::Authority::get_from_breeding().
In case of import via Z3950, MarcToUTF8Record() is called,
which calls SetMarcUnicodeFlag(),
which calls MARC::Record->encoding('UTF-8')
Test plan :
1) Use a UNIMARC database
2) Configure a connexion to a UNIMARC SRU, for example BNF,
see https://doc.biblibre.com/koha/autour_de_koha/serveurs_z3950_sru#serveur_de_la_bnf
3) Go to cataloguing module
4) Click on 'New from Z39.50/SRU'
5) Choose only the SRU target
6) Search for ISBN 2266072889
7) Confirm you see good encoding : diacritic on 'a' of title 'Strate-a-gemmes'
8) Click on 'Marc preview'
9) Confirm you see good encoding
10) Click import
11) Confirm you see good encoding
12) Check also Authorities import via SRU
13) Check also SRU imports on a MARC21 database
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: Removed change to new_from_xml call. We should respect syntax.
But the added MARC::Record encoding does the tric! Which is implicit
for Z3950 targets where MarcToUTF8Record does the same.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
One call to set_userenv had been implimented incorrectly with the
parameters out of order.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
You should be able to add desk choice when you are logging in or
changing library.
Test plan:
1. apply patch
2. have at least three libraries, one without desk, one with one and
one with a few.
3. At login, when choosing a library, it should enable all desks it
has. Pick one.
4. the desk id and name should be set in your session and appear in
the top right, next to the library name.
5. change library and desks from intranet (at the set-library.pl page)
6. you should have the same behaviours
7. if you have a library without a desk, it should prompt you a '---'
option and no desks will be attached to the session.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch updates the templates to use the new TT plugin instead of
adding additional variables to the already crouded get_template_and_user.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When Desks are defined, a librarian can attach a desk to its session.
Test plan:
1. apply 13881 and create some desks
2. you should see “NO DESK SET” in the intranet header
3. go to circulation > Set desk
4. you should see your desk name in the header, whatever the page
5. you can also set desk with the header menu
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We removed the single occurrence of this subroutine in the previous
patch
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the hooks be called only if the checkin is effective
(i.e. if it is not rejected for some reason.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Circulation_hooks.t
=> FAIL: Tests fail
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is certainly a major issue that leads to many side-effects.
Under plack, the structure of the default values are not handled
correctly.
Package variables are used to store stuff like the "layout type". They
are complex structures (arrays of hashes) and returned without being
copied.
When the caller (the controller script) retrieve them then modify the
returned structures, it actually modifies the package's variables.
One of the issue is:
Create a new layout
The script retrieve a structure with all "selected" flags are set to 0
It select the first one as default (BAR as selected => 1)
The user creates the new layout and will selected BIBBAR (for instance)
If you then edit this new layout, the script will retrieve the
"label_types" and set "selected" for BIBBAR. However BAR is still
selected!
The UI receives 2 selected and display the first selected one that has
the selected option.
Test plan:
1. Create a layout type for Barcode/Biblio
2. Choose fields to print and size of font
3. Save
4. Edit existing Layout
=> Withtout this patch "Barcode" is the preselected option
=> With this patch applied, the correct "Barcode/Biblio" option is
selected
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
AddReturn can be called on an item even if it's not checked out (to
trigger holds for instance).
The hook should (?) not be called in that situation
Test plan:
Confirm the above and that the following tests are now passing:
t/db_dependent/SIP/Message.t
t/db_dependent/Reserves.t
t/db_dependent/Circulation/issue.t
t/db_dependent/SIP/Transaction.t
t/db_dependent/Circulation.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch gets rid of a helper method used for calling the plugin
hooks.
To test:
1. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Circulation_hooks.t
=> SUCCESS: Tests pass!
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests still pass!
4. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch simplifies the payload as suggested on bug 25855. It also
keeps some specific params that cannot be deduced from the passed
checkout object, (e.g. if it is an onsite checkout).
Tests are cleared and added for this special exceptions.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a call to _after_circ_actions into AddIssue and passes
an appropriate payload for plugins to utilise after issuing items.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It is called after a hold has been placed
Test plan:
1. Write a plugin that implements only after_hold_create (see
`perldoc Koha::Plugins` for implementation details). Install it and
enable it
2. Place a hold and verify that your plugin method has been called with
the right parameters
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Pasi Kallinen <pasi.kallinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the hook be passed the Koha::Checkout object instead
of a hand-crafted list of attributes.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch generalizes the hook so it can be used by other circulation
actions.
Tests are also simplified by mocking some of the (extensive) plugin
hooks.
To test:
1. Repeat the test plan on the original patch
=> SUCCESS: All good
2. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a new hook to notify plugins about renewal actions. To
test it:
1. Apply the unit tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Circulation_hooks.t
=> FAIL: The tests expect some warnings to show, and they don't (i.e.
the sample plugin hook is not being called).
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass! The hook is being called on renewal!
5. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In an effort to use more inclusive language we have added a new coding guideline:
https://wiki.koha-community.org/wiki/Coding_Guidelines#TERM3:_Inclusive_Language
This patchset renames a syspref to be clearer and follow the guideline
To test:
1 - Apply patch and updatedatabase
2 - git grep NotesBlacklist
3 - Note all remaining occurrences are translations, db updates, and release notes
4 - Add a field (e.g. '520' ) to the NotesToHide systempreference
5 - View a record with a 520 field on the opac
6 - Confirm the field does not show in the 'Title notes' tab
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It appears that we are quoting the ccode values deep in the search code.
Under ICU chains this breaks searching by limits
To recreate
1 - Setup Koha using Zebra and icuchains
2 - Add ccode to AdvancedSearchTypes
3 - In koha-conf.xml set zebra debug level to include request
<zebra_loglevels>none,fatal,warn,request,info</zebra_loglevels>
4 - Set some items into different ccodes
5 - On opac perform a search for:
ccode:NFIC
6 - It works
7 - tail -n 50 /var/log/koha/kohadev/zebra-output.log
8 - Note search request like:
Search biblios OK 26 1 1+0 RPN @attrset Bib-1 @attr 1=8009 NFIC
9 - On opac go to advanced search, select Collection, and limit to smae code a s above
10 - No results
11 - Check the zebra-output.log:
Search biblios OK 0 1 1+0 RPN @attrset Bib-1 @attr 1=8009 'NFIC'
12 - Apply patch
13 - Restart all
14 - Repeat search by collection limit
15 - Success!
16 - Check the zebra-output.log:
Search biblios OK 0 1 1+0 RPN @attrset Bib-1 @attr 1=8009 NFIC
17 - Add a new ccode value: N)N
18 - Set some items to that ccode
19 - Confirm searching by that ccode works
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I can not see how this code is useful here. It checks for a reserve with priority 0 and found = NULL
That is not a status that should occur when filling a transfer. Either the found is 'T' if we are transferring due
to the hold, or the hold was placed after the transfer was initiated, and so the priority is not 0
Additional, AddReturn checks for reserves later and asks the staff to confirm waiting status.
ModReserveStatus also calls CartToShelf regardless of what happens here.
To test:
1 - Set UpdateItemLocationOnCheckin to:
_ALL_: CART
2 - SetAutomaticItemReturn = Do
3 - Check an item in at a different branch than it's homebranch to create a transfer
4 - Check the item in at it's homebranch
5 - View the item details page
6 - Item is not in CART location
7 - Apply patch
8 - Repeat
9 - Item is in CART location after completion of transfer
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jason Robb <jrobb@sekls.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch builds on Bug 22318 to move the opaccredits system
preference into the Koha news system, making it possible to have
language- and library-specific content.
To test you should have some content in the opaccredits system
preference. Apply the patch and run the database update process.
- Go to the OPAC and confirm that the content which was previously in
the opaccredits system preference now displays correctly where
it was before.
- In the staff client, go to Tools -> News and verify that the content
from opaccredits is now stored in news items. There should be
one entry for each of the enabled translations in your system, for
instance 'opaccredits_en', 'opaccredits_fr-FR',
'opaccredits_cs-CZ'
- Go to Administration -> System preferences and confirm that the
opaccredits preference has been removed.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The template plugin Branches contains a method GetLoggedInBranchcode that returns current branch code.
This patch adds GetLoggedInBranchname to get current branch name.
It is used to replace vars LoginBranchname and LoginBranchcode sent to all templates in C4/Auth.pm.
In labels and patrons cards modules, I choose to remove a unseless display of
current branch in a hint.
In acqui/acqui-home.tt, I choose to remove a useless display of current
branch and also because table of founds contains a filter on library.
Test plan:
Check pages source code to see branch code or name is correct.
list of the pages:
/cgi-bin/koha/acqui/acqui-home.pl
/cgi-bin/koha/catalogue/detail.pl?biblionumber=XXX
/cgi-bin/koha/circ/branchoverdues.pl
/cgi-bin/koha/circ/set-library.pl
/cgi-bin/koha/circ/offline.pl
/cgi-bin/koha/labels/label-edit-batch.pl?op=new
/cgi-bin/koha/labels/label-manage.pl
/cgi-bin/koha/patroncards/edit-batch.pl
/cgi-bin/koha/patroncards/manage.pl
OPAC:
/cgi-bin/koha/opac-detail.pl?biblionumber=XXX
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This adds the ability to not refund lost item fees on return if the item
has been lost for more than a given number of days.
Test Plan:
1) Set the new system preference NoRefundOnLostReturnedItemsAge to a number of days
2) Find a lost item that has been lost longer than that NoRefundOnLostReturnedItemsAge days which would have otherwise been refunded
3) Return the item
4) Note no refund on the lost item fee was processed, the fee remains unchanged
5) prove t/db_dependent/Circulation.t
Signed-off-by: Deb Stephenson <DStephen@dubuque.lib.ia.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Added a feature that displays edition information of the book
together with title in "Holds queue" report.
Edition information is fetched from "biblioitem" table
as "editionstatement" and transferred to template.
1. Place a hold on a book with edition information.
2. Run build_holds_queue.pl cron job.
3. Go to /cgi-bin/koha/circ/view_holdsqueue.pl and check the "title"
table of that book that you placed hold on.
4. Observe that there's no information about edition of that book.
5. Apply patch.
6. Repeat step 3.
7. Observe that cinformation about edition of that book appeared
in the title table after book's title and author.
Mentored-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When a holiday is entered, then exceptions generated on a range, there exists both a holiday and exception in
the special holidays table. We should cache the exception over the holiday instead of both
Also, !1 in perl returns '' rather than 0, so we should explicitly set the value
Add blank line to clear pod error from qa tools
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Re-introduce the blank line mentioned in the commit message, it was accidentally removed by automatic formatting
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch updates the previous single_holidays and exeption_holidays
cache flushing calls to match the new cache key structure of the updated
routines.
Signed-off-by: Emma Perks <Emma.Perks2@uhb.nhs.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some SIP devices need access to item fields that are not sent as item information in the checkin, checkout and item information responses.
It makes sense to allow these fields to be sent in an arbitrary and configurable way, rather than hard code in each special case.
Test Plan:
1) Apply this patch
2) Edit your SIP2 config file, add the following within the login stanza:
<item_field field="XX" code="<item field 1>" />
<item_field field="XZ" code="<item fied 2>" />
where <item field 1> and <item field 2> are item table columns of your choosing
3) Using the sip cli emulator, run checkout, checkin and item information
messages using that item.
4) Note the values you set for the item columns are sent in the
corrosponding fields!
Signed-off-by: Jill Kleven <jill.kleven@pueblolibrary.org>
Fixed merge conflict with number of tests (was 5, changed to 7 which is correct)
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To make sure we will update all the objects in one go (and no trigger
the ->set->store from Koha::Object->update)
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are using raw SQL statements, we should use Koha::Hold instead.
This patch does not seem optimal, we would like to increment priority in
only 1 statement and without the need to fetch and loop all holds.
== Test plan ==
- apply patch
- place some holds on the same record
- check that the priorities look good
- mark one hold as waiting by doing a check-in
- revert the waiting status
- confirm that the priorities are recalculated correctly
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves the accountline->store call below the FinesLog code
such that we return the same 'thing' from _FixOverduesOnReturn as the
other clauses of the routine.
We also take the oportunity to clean up the warning thrown by an errant
call to the routine such that we output the actual itemnumber rather
than a HASH reference marker.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes any overdues which would be reversed on a backdated
return if CalcFineOnBackdate is enabled and the user has not already
attempted to pay off the accruing fine.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The item's location where not passed to UpdateStat
Signed-off-by: Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is the commit where you will find useful information about this development.
The goal of this new feature is to add a way to pseudonymize patron's
data, in a way they could not be personally identifiable.
https://en.wikipedia.org/wiki/Pseudonymization
There are different existing way to anonymize patron's information in
Koha, but we loose the ability to make useful report.
This development proposes to have 2 different tables:
* 1 for transactions and patrons data (pseudonymized_transactions)
* 1 for patrons' attributes (pseudonymized_borrower_attributes)
Entries to pseudonymized_transactions are added when a new transaction
(checkout, checkin, renew, on-site checkout) is done.
Also, anonymized_borrower_attributes is populated if patron's attributes are
marked as "keep for pseudonymization".
To make those informations not identifiable to a patron, we are having a
hashed_borrowernumber column in pseudonymized_transactions. This hash will be
generated (Blowfish-based crypt) using a key stored in the Koha
configuration.
To make things configurable, we are adding 3 sysprefs and 1 new DB
column:
* syspref Pseudonymization to turn on/off the whole feature
* syspref PseudonymizationPatronFields to list the informations of the
patrons to sync
* syspref PseudonymizationTransactionFields to list the informations
of the transactions to copy
* DB column borrower_attribute_types.keep_for_pseudonymization that is a
boolean to enable/disable the copy of a given patron's attribute type.
Test plan:
1/ Turn on Pseudonymization
2/ Define in PseudonymizationPatronFields and
PseudonymizationTransactionFields the different fields you want to copy
3/ Go to the about page
=> You will see a warning about a missing config entry
4/ You need to generate a key and put it in the koha-conf.xml file. The
following command will generate one:
% htpasswd -bnBC 10 "" password | tr -d ':\n' | sed 's/$2y/$2a/'
Then edit $KOHA_CONF and add it before of the end of the config section (</config)
it should be something like:
<key>$2a$10$PfdrEBdRcL2MZlEtKueyLegxI6zg735jD07GRnc1bt.N/ZYMvBAB2</key>
5/ Restart memcached then plack (alias restart_all)
=> Everything is setup!
6/ Create a new transaction (checkin for instance)
=> Confirm that a new entry has been added to pseudonymized_transaction with the data
you expect to be copied
7/ Edit some patron attribute types and tick "Keep for pseudonymization"
8/ Create a new transaction
=> Confirm that new entries have been added to pseudonymized_borrower_attributes
11/ Delete the patrons
=> Confirm that the entries still exist in the pseudonymized_* tables
12/ Purge the patrons (ie. use cleanup_database.pl to remove them from
the deleted_borrowers table)
=> Confirm that the entries still exist in the pseudonymized_* tables
See bug 24152 to remove data from the anonymized_* tables
Sponsored-by: Association KohaLa - https://koha-fr.org/
Signed-off-by: Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Find or create a record with 10 items
2 - Set sysprefs:
decreaseLoanHighHolds - enable
decreaseLoanHighHoldsDuration - 2
decreaseLoanHighHoldsValue - 2
decreaseLoanHighHoldsControl - 'over the number of holdable items'/dynamic
3 - Set circ rules to allow 1 hold per record on the relevant record
4 - Place 3 holds on the record
5 - Check one item in and confirm hold to set to waiting
6 - Issue to the patron with the waiting hold
7 - Get a notice that loan period is decreased
8 - Don't confirm the checkout
9 - Apply patch
10 - Restart all the things
11 - Repeat checkout, no decrease this time!
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If the subroutines are not exportable we get the following crash:
> Undefined subroutine &C4::SIP::SIPServer::set_logger
To test:
In kohadevbox run for example:
$ ps -aux # check that no existing sip server is running, kill the process if exists
$ perl /kohadevbox/koha/C4/SIP/SIPServer.pm /etc/koha/sites/kohadev/SIPconfig.xml
$ koha/misc/sip_cli_emulator.pl -su koha -sp koha -l CPL -a 127.0.0.1 -p 6001 --item 3999900000001 -m item_information
After applying this patch the Undefined subroutine error should be gone.
Note: when using the sip_cli_emulator.pl the credentials can be anything.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Coming from:
Bug 23463: Use new method Koha::Object->set_or_blank
We have DB fields that are not mapped with MARC fields, for instance paidfor. They are not handled correctly.
In ModItemFromMarc, we get a MARC record in parameter and update the item in DB. But we are loosing the fields that are not in the MARC record
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If 'Actual cost' has not been set then it has the value of 0.00 which
Perl evaluates to true so this patchset resets it to 0, so the fallback
to ecost_tax_included/ecost_tax_excluded happens.
Test plan:
1. Add item to acquisition basket (make sure the vendor has: tax rate: 15%, 'List prices: Include tax', 'Invoice prices: Include tax')
2. Set 'Vendor price' = 10 and do not set 'Actual cost'
3. Save order
4. Observe basket.pl shows 'Total tax exc.' has a value of 0.00 and GST
column has value of -8.70
5. Jump into the database:
select tax_value_on_ordering from aqorders where
ordernumber=<ordernumber>;
[You can get the ordernumber from clicking on the 'Modify' line the item
is listed in]
6. Observe a negative value: -8.70
7. Apply patch and restart plack
8. Add a second item to the basket
9. Set 'Vendor price' = 10 and don't set 'Actual cost'
10. Save order
11. Observe basket.pl shows 'Total tax exc' has value of 8.70 and GST
has value of 1.30
12. Repeat step 5 and observe tax_value_on_ordering = 1.30
13. Run t/Prices.t unit test:
sudo koha-shell <instancename>
prove t/Prices.t
Sponsored-by: Horowhenua District Council, NZ
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
% prove t/db_dependent/Serials.t
t/db_dependent/Serials.t .. 8/49 "my" variable $DEBUG masks earlier declaration in same scope at /kohadevbox/koha/C4/Barcodes/ValueBuilder.pm line 45.
"my" variable $DEBUG masks earlier declaration in same scope at /kohadevbox/koha/C4/Barcodes/ValueBuilder.pm line 87.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes some new error cases introduced during rebase
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a .perlcriticrc (copied from qa-test-tools) and fixes
almost all perlcrictic violations according to this .perlcriticrc
The remaining violations are silenced out by appending a '## no critic'
to the offending lines. They can still be seen by using the --force
option of perlcritic
This patch also modify t/00-testcritic.t to check all Perl files using
the new .perlcriticrc.
I'm not sure if this test script is still useful as it is now equivalent
to `perlcritic --quiet .` and it looks like it is much slower
(approximatively 5 times slower on my machine)
Test plan:
1. Run `perlcritic --quiet .` from the root directory. It should output
nothing
2. Run `perlcritic --quiet --force .`. It should output 7 errors (6
StringyEval, 1 BarewordFileHandles)
3. Run `TEST_QA=1 prove t/00-testcritic.t`
4. Read the patch. Check that all changes make sense and do not
introduce undesired behaviour
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
0) Apply the patch
1) Go to all of these pages
Patron detail
Other patron pages - look on the left side (circ-menu)
Patron search
Guarantor search ( go to child patron -> edit -> in guarantor
section click "Set to patron"
Search through "Check out" (in the header)
2) Confirm that does show date of birth and date consistantly,
try it on patrons with and without date of birth set to find
possible reggressions
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If we limit the JOIN to rows with the correct subpermission we won't
duplicate the returned patrons
To test:
1 - Give a patron full acquisitions permissions
2 - Also give them several subpermissions on other areas
3 - Go to Acquisitions
4 - Edit a fund
5 - Add a user to the fund
6 - Search for user above
7 - They return multiple times in results
8 - Apply patch
9 - Restart all the things
10 - Repeat search
11 - Patron appears once
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This warning was thrown:
Use of uninitialized value $info{"invalid_username_or_password"}
in numeric eq (==) at /home/vagrant/kohaclone/C4/InstallAuth.pm
line 387.
There is the case when hash key can be undefined in numeric comparison.
Fixed by adding additional precheck for
$info{"invalid_username_or_password"} being Perl's "true".
To test:
1) Go to the first page of the web-installer where it asks to login.
2) Observe the warning in the log file.
3) Apply patch.
4) Repeat step 1.
7) Check that previous warning suppressed.
Mentored-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
* Add POD to get_table_settings
* Remove USE Dumper debug statement
* Add missing "10" entry
* Fix newly created test file (and renamed)
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch is the main patch of this patchset, you will find the
description and the test plan.
The idea of this new enhancement is to add the ability to define the
default sort order and the default number of rows displayed on the
acquisition basket page.
The existing "columns settings" feature was replaced by a
"tables settings" feature. To prepare the ground, there were some
works that were needed:
* rename variables and files
* Modify the structure of the yml files
* Create a new DB table to store the tables settings
Test plan:
0)
a. Execute the update DB entry to create the new table
b. Restart all (to get a new version of the yml file, that is cached by
memcached)
c. Create several orders for a given basket
1) Go to the basket view page
=> The default values are the same than without this patchset, the
number of entries to display is set to "20" and the table is sorted by
basket number (first column)
2) Go to the "Columns settings" page
3) Unfold the "Acquisition" tab
=> Notice the 2 dropdown lists at the bottom of the basket table
4) Select different values for "Default display length" and "Default
sort order"
5) Refresh the basket view page
=> Notice that the default settings are now effective on the table
QA note: We can decide to replace the different occurrences of "Columns settings"
by "Tables settings" if needed.
Sponsored-by: Institute of Technology Tallaght
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are preparing the ground with this patch. As the "Columns settings"
page will now add the ability to modify settings for the whole table, it
makes sense to rename the file and the variables.
Note that the controller script (admin/columns_settings.pl) and the yml
(admin/columns_settings.yml) files have not been moved to not break
shortcuts and abits people could have. But if QA decides, it could be
easy to do.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch changes the new circulation rule that's introduced from
useDaysMode to daysmode to improve consistency with other rule names.
We also update the accessors and code using them to reflect the new
term.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are 3 other occurrences where the new circ rule can be used:
* C4::Circulation::checkHighHolds
* Koha::Hold->set_waiting
* misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl
Test plan:
* checkHighHolds
Enable decreaseLoanHighHolds and fill decreaseLoanHighHoldsDuration
Setup things to hit a "high demand" alert with a shortened due date
Check an item out
=> The due date must be recalculated depending on the circ rule useDaysMode.
* set_waiting
Set ExcludeHolidaysFromMaxPickUpDelay to "1" (note that there is currently
a bug in the description of the syspref, see bug 22381 comment 19)
Mark a hold waiting
The expiration date should have been set depending on the value of the
circ rule.
* TalkingTech cronjob
Cannot test this
Signed-off-by: Simon Perry <simon.perry@itcarlow.ie>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Moving the useDaysMode system preference to a circulation rule will add
much more flexibility in the calculation of the due date.
The initial request was to make hourly loan returned on closed when
(when checked out on the same close day).
To do so we do not want to take into account the calendar.
However the calendar need to be taken into account for other loan item types.
Other scenarios are possible, for instance depending on the branch.
This patchset will add a new "Days mode" column (next to "Loan period")
to the circulation rules page, with the different values of the
"useDaysMode" system preference + a "default" value, to default to the
system preference value.
Test plan:
- Define a long loan item type (like 10 days) that will use the calendar
(or default to the pref value, if the pref is not set to "ignore the
calendar")
- and a hourly loan (like 2 hours) that will ignore the calendar
- Create items with those item types
- Mark today as a closed day
- Check the items out
=> The hourly loan is due the same day
=> The other loan is due on an open day
QA note:
There is the need to force the "days_mode" option when Koha::Calendar is
initiated for the due date calculation. To make sure devs will not
forget it, the methods that need have it defined will throw an
exception.
Sponsored-by: Institute of Technology Carlow
Signed-off-by: Simon Perry <simon.perry@itcarlow.ie>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is a companion/alternative to bug 25184, in that it allows an
explicit workflow for placing returned books into temporary storage for
a few days for decontamination purposes.
The idea here is to create a specific notforloan value for "In
Decontamination" or something along along those lines. This notforloan
value would never be trappable. At the end of decon,
UpdateNotForLoanStatusOnCheckin could be used to remove the
notforloan status and allow checkins to be trapped to fill holds.
Test Plan:
1) Apply this patch
2) Restart all the things!
3) Give an item a negative notforloan value
4) Place a hold on the item
5) Check the item in
6) Note the item is trapped for hold
7) Set SkipHoldTrapOnNotForLoanValue to the same notforloan value
you used in step 3
8) Check the item in again
9) Note Koha did not ask you to trap the item for hold!
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This bug is basically the same as bug 24966, but for hold_patron_name instead of hold_patron_bcode.
The subroutine hold_patron_bcode should always return an empty string, not undef.
Test Plan:
1) Using the SIP cli emulator, checkin an item that is not checked out
2) Note the DA field contains someting like "C4::SIP::SIPServer=HASH(0x88175c8)"
The hex number will almost certainly be different from this example
3) Apply this patch
4) Restart the SIP server
5) Run the SIP checkin again
6) Note the DA field is no longer present!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Automatic authority creation assumes that if we don't match we need a new authority.
Using the Default linker, however, we don't match if there exists more than one match.
This leads to repeatedly generating authorities once there is a duplicate in the system
We shoudl instead only create a new authority if there are no results
To test:
1 - Set Linker Module to 'Default'
2 - Enable AutoCreateAuthorities and BiblioAddsAuthorities and CatalogModuleRelink and LinkerRelink
3 - Add two copies of a single authority via Z39
4 - Add a heading for that authority to a bib record
5 - Save the record and note a new authority is generated
6 - Repeat and see another is generated
7 - Apply patch
8 - Restart all the things
9 - Save the record again, no new authority created
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 23934 removed the limitation that prevented item level holds from
getting local holds priority. The problem is the code has never checked
if the item level hold matches the given item! This means the wrong item
may be requested to fill an item level hold.
Test Plan:
1) Create 3 items on a record
2) Place a hold for the 2nd item you created
4) Ensure that hold would be picked up by local holds priority
5) Build the holds queue
6) Note the holds queue is asking for the wrong item!
7) Apply this patch
8) Rebuild the holds queue
9) Holds queue should now be asking for the correct item!
Signed-off-by: Kim Peine <kim@williston.lib.vt.us>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The holds queue builder does not honor
the new item_level_hold flag. Instead, it only item_level_request if
in the loop dealing with item level holds. This is incorrect. Item level
holds may be trapped in the local holds priority loop as well. It's
trivial to just pass though the correct item/biblio level hold flag.
I do not know how to write a reproducable test plan for these issues.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kim Peine <kim@williston.lib.vt.us>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
WWW::YouTube::Download is broken and not reliable.
Other alternative was to use HTML::Video::Embed but not updated since
years.
The best alternative seems to follow youtube advise and use an iframe
https://developers.google.com/youtube/iframe_api_reference
Test plan:
Put youtube video in 856$u (using different url formats, youtu.be,
youtube.com/embed, etc.)
Enable HTML5MediaEnabled and HTML5MediaYouTube and confirm that the
youtube videos are correctly embeded.
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This was the only occurrence of GetBooksellersWithLateOrders and it was
the only subroutine of C4::Bookseller
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It seems that this regression comes from bug 14419, but I have not found
a logic reason behind that.
This patch restores the behaviour we always had: facet groups must be
displayed in a given order: the Zebra index (au, ccode, holdingbranch,
etc.)
Test plan:
Apply this patch, restart all and confirm that the facets are not moving
up and down when you refresh your search result page.
QA note:
I think the following line must be removed
@facets_loop = sort {defined $a->{expand} && defined $b->{expand} && $a->{expand} cmp $b->{expand}} @facets_loop;
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In order to prevent typos or further regressions it is better (I think)
to have this code into a loop
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the code set the *_storage fields when adding new
fields to an existing course item. And reverts those fields correctly
when removing the item from the course.
If a new field is enabled on an existing course reserve, the storage
field is not given a value, so when the item goes off reserve, the
item field will always be updated to NULL.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/CourseReserves/CourseItems.t
=> FAIL: Tests fail, data is not reverted correctly
3. Apply this patch and repeat 2
=> SUCCESS: Tests pass! Data is correctly reverted
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As we are now removing them from MarkIssueReturned they should not be
removed from AddReturn as well.
Also I think this will fix a regression, if $doreturn is not set (in
case the item is withdrawn and BlockReturnOfWithdrawnItems or the item
is lost and BlockReturnOfLostItems, and other specific cases).
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It's quite hard to know where this need to be fixed.
it can be either MarkIssueReturned or LostItem, depending on the
different cases we want to handle.
This patch picked MarkIssueReturned, but maybe the similar code in
AddReturn needs to be removed then.
== Test plan ==
1. Set MarkLostItemsAsReturned to 'from items tab of the catalog module'
2. Set AutoRemoveOverduesRestrictions to 'Do'
3. Set up an overdues restriction in the notice triggers
4. Check out an item and let the overdues process restrict the account
5. Navigate to the moredetail.pl page (items tab) for the overdue item
6. Mark the item lost
7. Return to the account in question - notice the item has been returned, but the restriction remains
8. Clean state: remove restriction + remove item lost status
9. Apply patch
10. Redo the test but this time in addition to the item being returned,
the restriction will be lifted.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Now that we have the reserve_id PK on the reserves table we should use
it (instead of the couple borrowernumber, biblionumber)
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To make sure we are going to display the correct hold's info we need to
pass the reserve_id.
== Test plan ==
1. Add some content to HOLD_SLIP notice, e.g.
<h2>[% branch.branchname %]</h2>
<div>[% biblio.author %]<br>[% biblio.title %]<br>[% item.barcode %]
<ul><li> Reserve ID: [% hold.reserve_id %]</li>
<li>Expiration date: [% hold.expirationdate %]</li></ul>
2. Add 2 holds for 1 patron to a single record
3. Check the reserve IDs in the reserves table - on a clean sandbox, they will be 1 and 2
4. Check in one of the items from the record and print the slip
5. Note that the reserve ID on the slip is 2 and the expiration date is blank
6. Repeated check ins do not change this
7. Check in a second item from the record
8. Note that the reserve ID for this hold is also 2, but this time the expiration date is filled in
9. Check in the first item again - the reserve ID stays as 2, but this time the expiration date is filled in
10. Apply patch
11. cancel the holds to come back to a clean state
(and maybe ensure items aren't in transit)
12. redo the test and see the following differences
13. 1st checkin:
1. expiration date ok
2. the reserve ID is the one of the first hold
14. 2nd checkin:
1. expiration date ok
2. the reserve ID is the one of the second hold
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If think this case does not apply to real-life, but the logic needs to
be fixed.
If an item is due now, and AddReturn is called now with a return date in
the future, the issue is overdue and the patron must be debarred.
However it is not as we compare with now and not the return date
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In an OO package, the logger initialization should happen in the
constructor. This is not an OO package and the initialization is
happening on loading it. This is a wrong behaviour and certainly breaks
in environments where initialization cannot happen (package building,
for example). There could be several options to solve this, as it is
used in a single sub on this package, I opted for initializing on that
sub.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
== Test plan ==
1 - Have two patrons with userids and no cardnumber
2 - Note which of these has the higher borrower number
3 - Use the SIP cli emulator to connect and checkout a book to the patron with higher borrowernumber
See example after
4 - Note the book may checkout to the wrong patron!
5 - Apply patch
6 - Checkout to both patrons via sip
7 - The patrons get the correct checkouts
=== SIP CLI emulator ===
./misc/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -su term1 -sp term1 \
-l CPL --patron 23529001000463 -m checkout --item 39999000001259
translation: via the koha user term1, checkout item 39999000001259 to
patron 23529001000463
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch implements the use of the ViewPolicy record processor filter
inside C4::Search::searchResults. The idea is that the $record_processor
is instantiated once and reused inside the loop. This leaves options for
further optimizations I will do on a follow-up bug.
The filter is applied to the MARC data before it is passed to the XSLT
processor.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Search.t
=> FAIL: This is not implemented, tests fail
3. Apply this patch
4. Repeat 2
5. Feel the joy in your body from a long standing bug being solved
6. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes use of the 'variables' parameter in XSLTParse4Display
method in the different places that it is used in the OPAC. It does by
passing this parameter with
anonymous_session => 1|0
The value will depend on the output from get_template_and_user (i.e. if
there's a returned borrowernumber).
A special case takes place in search results, as the call to
XSLTParse4Display happens in C4::Search::searchResults. So a new
parameter 'xslt_variables' is added to it.
To test:
1. Apply the [DO NOT PUSH] patch
2. Open the OPAC in your browser
3. Try detail pages, search results, tags and lists/shelves pages with
or without an active session
=> FAIL: It always says (somewhere) 'Anonymous session: Yes'
4. Apply this patch, restart_all
5. Repeat 3
=> SUCCESS: It will tell the Yes/No correctly regarding anonymous
sessions!
6. Sign off :-D
Sponsored-by: Universidad ORT Uruguay
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Koha::Account->add_credit is expecting a positive amount.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
* We should not call Log::Log4perl directly
* Not sure it is correct as I get from (comment 77):
% koha-sip --restart
[2020/04/23 11:23:27] [ERROR] [undef]@[undef]: Argument "0.33_01" isn't
numeric in numeric lt (<) at /usr/share/perl5/Net/Server/Log/Sys/Syslog.pm
line 42.
C4::SIP::Trapper::PRINT /kohadevbox/koha/C4/SIP/Trapper.pm (24)
Why "ERROR" when it's a warning?
The [undef]@[undef] seems wrong here.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Now that we have Koha::Logger, we should use it in our SIP server. This
has the potential to make debugging SIP issue much easier. We should add
the userid for the sipuser to the namespace so we can allow for separate
files per sip user if wanted.
Test Plan:
1) Apply this patch set
2) Update the modififed log4perl.conf to your system
3) Restart your sip server
4) Tail your sip2.log, run some queries
5) Note you still get the same output messages as before, with the
addition of the ip address and username ( if available )
prefixing the message.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Lines can be moved. Deletion can be done too if skip_merge is not set.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It's entirely possible that some libraries are relying on the current
before for part of their workflow. Do to this possibility, it seems like
a good idea to control this behavior via a system preference.
Test Plan:
1) Apply this patch set
2) Run updatedatabase.pl
3) Set TrapHoldsOnOrder to "don't trap"
4) Set an item's notforloan value to -1
5) Place a hold on that item
6) Check in the item
7) Note the item is not trapped for hold
9) Set TrapHoldsOnOrder to "trap"
10) Check in the item
11) Koha should now ask if you'd like to trap the item for the hold!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Negative notforloan statuses should allow holds to be placed but not captured.
Due to coronavirus, we have libraries setting all returned materials to a negative notforloan value of Quarantine for several days.
They're using UpdateNotForLoanStatusOnCheckin to set that status automatically. However, those items are still capturing for holds,
even though those items cannot be checked out until the notforloan status is removed.
In cases like an On Order item where we do want the hold to fill at checkin,
UpdateNotForLoanStatusOnCheckin should be used to clear that notforloan status so the hold can fill.
In master, if I set an item to a not for loan but holdable status ( < 0 ) I can place the hold,
capture the hold and set it to waiting, but *not* check it out to the patron!
This does not make sense. I should not be able to trap an item for checkout unless it can be checked out.
Test Plan:
1) Set an item's notforloan value to -1
2) Place a hold on that item
3) Check in the item
4) Trap the item for that hold
5) Attempt to check the item out to the patron, you will be unable to
because it is notforloan
6) Apply this patch
7) Restart all the things!
8) Repeat steps 1-3
9) The screen should no longer ask if the item should be trapped
to fill the hold!
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Catherine Ingram <Catherine.Ingram@cedarparktexas.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch fixes 2 other occurrences. The first one is in POD of
AddReserve, the other one fixes SIP code
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The parameter is branchcode, not branch.
Test plan:
Place a hold on a biblio using ILSDI
Check that the branchcode is correctly filled with the patron's library
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: Cork Institute of Technology
Signed-off-by: Angela O'Connor Desmond <angela.oconnordesmond@staff.ittralee.ie>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
So far we only record the number of claims and the date of the last
claim, in the aqorders table.
To keep track of the different claim dates, this patchset is going to
make the following DB changes:
* Create a new table 'aqorders_claims' (id, ordernumber, claimed_on)
* Remove the two columns from the aqorders table: claims_count and
claimed_date
This will allow to display the different claim dates where needed: on
the late orders page, and the basket page.
To avoid additional fetches of Koha::Acquisition::Orders, GetLateOrders
has been moved to Koha::Acquisition::Orders->filter_by_late
That way we are going to add consistency, robustness, and cover the
feature with new tests.
Test plan:
0/ Create a bunch of new orders. Make sure they are from different
vendor (with different delivery time).
1/ Go to the late orders page and claim some orders
2/ Reclaim some of those orders
3/ Confirm that you can see the different claim dates for a given orders
(the history of the late orders claims is kept and displayed)
4/ Bonus point: Regression tests:
a. Modify the closedate of the basket in the database. That
will allow you to make sure the patch set did not introduce regressions.
It would be good to test the different filters on the late orders page:
* delay
* Estimated delivery date from/to
* Vendor
b. Confirm that the subtotal and the total values from the late orders
page is correct.
c. Test the update database entry: do not apply these patches, claims
some orders against master. Apply the patch, execute the update DB entry
then confirm that the number of claims is correct (note that the dates
will not as it is not possible to guess them).
QA note: the branchcode parameter has been removed from filter_by_late.
At first glance it seems that it was not used.
Sponsored-by: Cork Institute of Technology
Signed-off-by: Angela O'Connor Desmond <angela.oconnordesmond@staff.ittralee.ie>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1) Create translation files for a new language
( cd misc/translator; ./translate create xx-YY)
A new language means one that isn't already in Koha, xx-YY=>something you
invent.
2) Verify double encoding
egrep "Aix-Marseille|Jean Prunier|periodika|Bokm" misc/translator/po/xx-YY-*
check strange strings
3) Apply the patch
4) Create po files again
( cd misc/translator; rm -f po/xx-YY*; ./translate create xx-YY)
5) Verify no more double encoding
egrep "Aix-Marseille|Jean Prunier|periodika|Bokm" misc/translator/po/xx-YY-*
check normal string
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
At some point some calls to maybe_add got an extra $server var in their
parameter lists. This doubled parameter does nothing and should be
removed.
Test Plan: No change in behavior should be noted
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1) Before the patch when one checks in something using the KOCT the last seen
date is not updated.
2) After the patch when one checks in something using the KOCT the last seen
date is updated.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Deactivating a from Course Reserves reverts Item's Shelving Location
correctly, then deleting the same course reverts the Course Reserve
Items to old shelving location values.
Test Plan:
1) Add items to a Course - make sure they all have shelving locations
prior to being added to the course.
2) When adding items change their shelving location to something else.
See that Shelving Location has changed; permanent location in
parentheses
3) Deactivated course
See that Shelving Location has changed back to its original location
4) Deleted course
See that Shelving Location has changed back to what was picked during
adding it to the Course.
5) Apply this patch, restart all the things!
6) Repeat steps 1-4, note the shelvig location is not lost!
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Hannah Olsen <holsen@duncanville.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch builds on Bug 22318 to move the OpacMainUserBlock system
preference into the Koha news system, making it possible to have
language- and library-specific content.
To test you should have some content in the OpacMainUserBlock system
preference. Apply the patch and run the database update process.
- Go to the OPAC and confirm that the content which was previously in
the OpacMainUserBlock system preference now displays correctly where
it was before.
- In the staff client, go to Tools -> News and verify that the content
from OpacMainUserBlock is now stored in news items. There should be
one entry for each of the enabled translations in your system, for
instance 'opacmainuserblock_en', 'opacmainuserblock_fr-FR',
'opacmainuserblock_cs-CZ'
- Go to Administration -> System preferences and confirm that the
OpacMainUserBlock preference has been removed.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1. Create a course (disabled)
2. Add a reserve to this course for an item and set a homebranch
different from the item's homebranch
3. Enable the course
4. Verify that the item's homebranch has changed
5. Disable the course
6. Verify that the item's homebranch was reset to its initial value
7. prove t/db_dependent/CourseReserves/CourseItems.t
Sponsored-by: Université de Lyon 3
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Sonia Bouis <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Even if a library allows returns of lost items, the SIP server returns the error message "Item lost, return not allowed" if the checkin was not ok for any reason other than it being withdrawn ( and withdrawn items not being returnable ).
The most clear example of this is that when a lost item is not checked out to a patron and is returned. SIP returns that message even though lost items *can* be returned. The actual problem being that the item was not checked out.
Test Plan:
1) Ensure you can return lost items
2) Mark an item as lost
3) Check it in via SIP
4) Note the message you get back is "Item lost, return not allowed"
5) Apply this patch
6) Restart your SIP server
7) Repeat steps 2 and 3
8) Note you no longer get the incorrect message!
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This reverts commit 80f1374f26.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This is the same fix as on bug 14662, which fixed the behaviour in
cataloguing, but for the item form in acquisitions.
The code assumes that if a subfield is marked as mandatory, there
should be no empty entry in the pull downs.
This assumption is not correct, as it leads to the first entry of the
pull down being preselected if there is no default set. As the field
can never be 'unset', there will never be a 'required' warning.
Furthermore, it might be counterproductive to use mandatory fields,
as it might be easily forgotten to change the preselected value and
those mistakes will be hard to find.
Correct behaviour would be to preselect the empty value when there is
no default. This means on saving the item an error message is triggered
and the cataloger is forced to set the value.
To test:
- This is best tested with an ACQ framework, but default can be used
when no ACQ framework was created.
- In your MARC bibliographic framework:
- In 952 make itemtype, classification source and some other pull downs
like location or collection mandatory and set them to visibel if needed
- Create a new basket with 'items created while ordering'
- Add a new order, an existing record with 942$c set will work best
- Add items for your order line
- Verify that the first value of each pull down is preselected,
there is no way to trigger the 'required' error
- Apply patch
- Add a new order line
- Verify that classification source is preselected according to the
DefaultClassificationSource system preference (try unsetting it later)
- Verify all mandatory fields can be set to empty
- Verify that you can't save before correctly setting them
- Change your frameworks and set a default for itemtype (Ex: BK) and
another mandatory and non-mandatory field of your choice
- Add a new order line and item and verify the defaults are selected
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch fix the missing xml prolog in translated
files, XML or TT.
Is fixed teaching C4::TTParse not to ignore <?..?> constructs,
then teaching xgettext.pl to ignore those strings. Net result is
that they are copied in the translated file.
To test:
1) Update & install your preferred language,
(cd misc/translator/; perl translate update xx-YY; perl translate install xx-YY )
2) Compare the first lines (head -2) of:
koha-tmpl/opac-tmpl/bootstrap/en/xslt/compact.xsl
koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-opensearch.tt
koha-tmpl/intranet-tmpl/prog/en/xslt/plainMARC.xsl
and
koha-tmpl/opac-tmpl/bootstrap/xx-YY/xslt/compact.xsl
koha-tmpl/opac-tmpl/bootstrap/xx-YY/modules/opac-opensearch.tt
koha-tmpl/intranet-tmpl/prog/xx-YY/xslt/plainMARC.xsl
Check the missing prolog
3) Install this patch, repeat 1 and 2, now the prolog is present
on translated files.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test and understand what's going on, you can try that bit of code:
my @a = qw( a b c a);
my @b = qw( b c d );
my @c;
@c = grep { 'a' eq $_ } @a ? 'ok' : ();
say @c;
@c = ( grep { 'a' eq $_ } @a ) ? 'ok' : ();
say @c;
@c = grep { 'a' eq $_ } @a ? ('ok') : (undef);
say @c;
The problem here:
Have patrons in 3 branches CPL, MPL, SPL
Have a non superlibrarian with edit_borrowers permission but
without view_borrower_infos_from_any_libraries, from CPL
Create a library group with CPL, MPL
Use that non superlibrarian to search for patrons
You can search for patrons fro CPL and MPL
BUT, edit the value for CPL, use SPL (edit the DOM)
Search and... oops
Apply this patch, try again
Also use a superlibrarian patron (and/or with view_borrower_infos_from_any_libraries)
and confirm that they can see all patrons
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
1 - You will need to enable SIP on your testing instance
cp etc/SIPconfig.xml /etc/koha/sites/kohadev/
sudo koha-start-sip
add a user listed in the SIPconfig to your system and give them permissions (superlibrarian works)
on koha-testing-docker you should be able to start sip with user koha/koha without any adjustments
2 - If you copied the above file you should be set to get custom field DE with dateexpiry
Otherwise edit the sip login for the user to have a custom section like:
<login id="koha" password="koha" delimiter="|" error-detect="enabled" institution="kohalibrary" encoding="utf8" >
<custom_patron_field field="DE" template="[% patron.dateexpiry %]" />
</login>
3 - send a status test using the sip cli tester:
perl misc/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -su koha -sp koha -l kohalibrary --patron 23529001000463 -m patron_status_request
4 - send an information test using the sip cli tester:
perl misc/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -su koha -sp koha -l kohalibrary --patron 23529001000463 -m patron_information
5 - confirm you receive the DE field with a dateexpiry
6 - Add your own custom fields and confirm it works with several
<custom_patron_field field="EW" template="Phone: [% patron.phone %] Email: [% patron.email %]" />
7 - prove -v t/db_dependent/SIP/Patron.t
8 - prove -v t/db_dependent/SIP/
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If maxFine is set, we total the patrons outstanding fines when making an adjustment, however, we neglect to count the amount of a currently updating fine when doing so.
To test:
1 - Set maxFine to 5
2 - Create an overdue amount of 4.99 for a patron
3 - Set an itemtype to have a fine of $.10 per day
4 - Checkout an item of that type to a patron and backdate the due date so it is overdue
5 - Run fines.pl with -v
6 - Note the fine is reduced from $.10 (or a multiple) to .01
7 - Run it again, a second cent is added
8 - Repeat and note it keeps happening until the amount of the fine is reached, exceeding the maxFine setting
9 - Apply patch
10 - Note the fine is now reduced to 0 and nothing is added to account
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Adding an item to course reserves and trying to edit any values in a second step does not work. Values are not saved and the table shows all values as "Unchanged".
This patch set adds two new sets of columns to the course_items table.
The first set determines if the specified column should be swapped or
not. The was previously 'implied' by the column being set to undef which
has been the root problem with that way of knowing if a column should
swap or not.
The second set of new columns are for storing the item field values
while the item is on course reserve. Previously, the column values
were swapped between the items table and the course_items table,
which leaves ambiguity as to what each value is. Now, the original
columns *always* store the value when the item is on course reserve,
and the new storage columns store the original item value while the
item is on reserve, and are NULL when an item is *not* on reserve.
Test Plan:
1) Apply this patch
2) Add and edit course items, not the new checkboxes for enabling fields
3) Everything should function as before
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In order to improve performance in the serial modules and add DB constraints,
this patch is going to add missing foreign key on the following columns:
* serial.biblionumber
* serial.subscription
* subscriptionhistory.biblionumber
* subscriptionhistory.subscriptionid
* subscription.biblionumber
Once done, some code can be removed from the Del* subroutines, as the ON
CASCASE clause will make the RDBMS handles the deletions.
Test plan:
0/ It would be useful to test the update DB entry on a big and old
production DB, to make sure the constraints will be added correctly.
We could remove the entries before creating the constraints, but it can
be unecessary
1/ Make sure you can recreate a fresh install with the kohastructure.sql
from this patch
2/ Make sure you can upgrade from a master install
3/ Create a subscription, serial, etc. and delete the biblio
=> The subscription/serials should have been deleted from the DB
4/ Create a subscription, serial, etc. and delete the subscription
=> The serials should have been deleted from the DB
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Implemented by calling GetMarcSubfieldStructure and improving
_check_split which may check repeatability in a specific framework,
and return the framework hash.
Test plan:
Run t/db_dependent/Biblio/TransformKohaToMarc.t
Optionally, follow the test plan of bug 21800#comment7.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Ere Maijala <ere.maijala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Just refactoring to make the next patch more readable
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This trivial patch adds a new convenient way to ask if Koha is
installed. It uses the same approach as C4::Auth:730
To test:
1. Apply this patch
2. Run:
$ kshell
k$ t/Context.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In Koha 18.11 backdating a return triggered a recalculation of the fine. This was removed in bug 14591, and I believe it was in error. The bug report itself has no justification for the change in behavior.
Test Plan:
1) Disable CalculateFinesOnReturn
2) Backdate an overdue with fines, note the fine does not change
3) Apply this patch
4) Repeat step 2
5) The fine should be updated!
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a clause in ModReserveAffect to check if there
are existing transfers and close them when setting a hold to waiting
To test:
1 - Set AutomaticItemReturn to Do
2 - Checkin an item from Library B at Library A
3 - Confirm item is in transfer (check the details page)
4 - Place a item level hold for pickup at library A
5 - Checkin the item at Library A
6 - Confirm the hold
7 - View the details page
8 - Note the item is in transit and waiting
9 - Apply patch
10 - Delete hold and repeat
11 - Confirm that transfer is closed when hold marked waiting
Signed-off-by: Sally <sally.healey@cheshirewestandchester.gov.uk>
Signed-off-by: Stina Hallin <stina.hallin@ub.lu.se>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
At this point the 2 subroutines are no longer in used.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To make sure the replacing code will acchieve the same things as the
actual one, we replace the raw SQL query with the DBIC version of it.
Then the tests will show us that they are equivalent.
Test plan:
Apply only this patch, run the tests, confirm they pass.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There are performance issues when searching suggestions if there are
thousands of suggestions.
To prevent that we are going to add the ability to archive purchase
suggestions, in order to remove them from the search list (by default).
Test plan:
0. Apply all the patches, execute the updatedatabase.pl script, restart
all
1. Create some suggestions
2. Search for them
3. Use the "Archive" action button for one of them
4. Restart the search
=> The archived suggestion does no longer appear in the list
5. Use the filter "Included archived" in the "Suggestion information"
filter box
=> The archived suggestion is now displayed
6. Use other filters
=> The "archived" filter is kept from one search to another
7. Use one of the action at the bottom of the suggestion list (change
the status for instance)
=> The "archived" filter is still kept
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It seems like ModReserveFill and ModReserveAffect should both produce action logs for holds.
Test Plan:
1) Apply this patch
2) Place a hold
3) Check in the item to trap the hold
4) Check out the item to fill the hold
5) Check the action logs for that reserve id
6) Note the new logs!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The wrong password might belong to an existing user. If that is the case,
we have a $patron.
Note that logaction will save the object info but has no user in the
context environment for a failure.
Test plan:
Login with good user, bad pw and bad user, bad pw. Check logviewer.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Add optional logging for successful and failing login attempts in
checkpw.
Test plan:
Enable the preferences
Perform a good login and a bad attempt
Check action_logs
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Just fixing documentation along the way.
No test plan, just read the patch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
Use serial with a numbering pattern with parentheses like "2018 (No. 1)".
Mark serial issue as arrived, check receivedlist on summary.
Edit issue again, check if not duplicated on receivedlist.
Mark issue as missing or not available, check missinglist.
Mark missing issue as not missing, check list again.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It is used in list context, but we need a scalar value.
Can be fixed by adding scalar's, or returning empty string as here.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
See bug 24800 comment 0 for a description of the problem.
We do not want the SIP server to crash if it receives a checkin request
with a return date that is not given.
The option this patch chose is to parse it only if provided.
Signed-off-by: Clemens Elmlinger <clemens.elmlinger@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It appears that a debugging statement was accidentally left in FeePayment.pm by bug 5605.
Signed-off-by: Devinim <kohadevinim@devinim.com.tr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If one tries to modify a suggestion that has no suggester you will get the following error:
Can't call method "lang" on an undefined value at /usr/share/koha/lib/C4/Suggestions.pm line 506
Koha assumes that every suggestion has a borrowernumber in suggestedby
Test Plan:
1) Create a suggestion with an unpopulated suggestedby
2) Attempt to modify that suggestion
3) Note the error
4) Apply this patch
5) Restart all teh things
6) Attempt to modify that suggestion
7) No error!
Signed-off-by: David Roberts <david@koha-ptfs.co.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Issue description:
- call to ModZebra was unconditional inside 'store' method for Koha::Item,
so it was after each item added, or deleted.
- ModZebra called with param biblionumber, so it is the same parameter
across calls for each items with same biblionumber, especially when we
adding/removing in a batch.
- with ElasticSearch enabled this makes even more significant load
and it is also progressively grows when more items already in DB
Solution:
- to add extra parameter 'skip_modzebra_update' and propagate it down to
'store' method call to prevent call of ModZebra,
- but to call ModZebra once after the whole batch loop in the upper layer
Test plan / how to replicate:
- make sure that you have in the admin settings "SearchEngine" set to
"Elasticsearch" and your ES is configured and working
( /cgi-bin/koha/admin/preferences.pl?op=search&searchfield=SearchEngine )
- select one of biblioitems without items
( /cgi-bin/koha/cataloguing/additem.pl?biblionumber=XXX )
- press button "add multiple copies of this item",
- enter 200 items, start measuring time and submit the page/form...
On my test machine when adding 200 items 3 times in a row (so 600 in
total, but to show that time grows with every next batch gradually):
WHEN ElasticSearch DISABLED (only Zebra queue):
- 9s, 12s, 13s
WHEN ElasticSearch ENABLED:
- 1.3m, 3.2m, 4.8m
WITH PATCH WHEN ElasticSearch ENABLED:
- 10s, 13s, 15s
Same slowness (because also same call to ModZebra) happens when you try
to delete all items ("op=delallitems"). And same fix.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch ensures call numbers are properly split for layout types
other than 'BAR'.
Test plan:
1. Go to Label Creator and choose/create a Label Layout with "Choose
layout type: Biblio"
2. make sure you have at least "itemcallnumber" in Bibliographic data to
print/Data fields
3. check "Split call numbers" box and save the layout (ie testlayout)
4. create a label batch, using items that have a call number (ie
DC611.B848 H84 1997). LCC is used here, but you may try with Dewey as
well.
5. export selected batch using any template and the layout you created
in previous step to a PDF
6. Call numbers are splitted (as expected) in the resulting PDF file
7. edit the layout you created in the previous step (ie testlayout) and
change the "Choose layout type:" to either Biblio/Barcode (BIBBAR) or
Barcode/Biblio (BARBIB)
8. export the same batch using the same template and layout as before
9. Call numbers are NOT splitted at all
After patch is applied, call numbers splitting functions are applied
even in Biblio/Barcode (BIBBAR) or Barcode/Biblio (BARBIB) layout types.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We should use Koha::DateUtils instead of Date::Time directly
This patch simplay replaces calls to now() with a call to dt_from_string()
which does effectively the same thing.
Probably reading the code and verifying changes is sufficient but...
To test:
1 - confirm the files all compile
2 - confirm all tests pass
3 - confirm Koha still works
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In C4/Utils/DataTables/Members.pm, the SELECT statement that fetches
patron data from the database does not include borrowers.othernames
in the field list. As a consequence, when the output is in the form
of a DataTable, the Template Toolkit files that refer to .othernames
(such as the patron-title.inc include) won't display the information
from the 'Other name' input field if that field has been filled in.
This patch fixes that.
Test plan:
0) Have a few patrons with some data in the 'Other name' field.
1) Perform a generic search in Home > Patrons to ensure you will get
a DataTable with results.
2) Observe that the 'Name' column does not include 'Other name' info.
3) Apply the patch, and restart Plack if necessary.
4) Repeat your search: this time you should see the information from
the 'Other name' field, it will be next to the patron's First name
and within parentheses.
Sponsored-by: Eugenides Foundation Library
Signed-off-by: Devinim <nazli@devinim.com.tr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To make this work I moved the _get_sub_length function from
subscription-add.pl to C4/Serials.pm so that the subscription-renew.pl
script could also call it to store the sublength for the appropriate
field of the subscriptions database table.
Test plan:
1. Create a subscription and notice that there is a dropdown box for sub
length containing the values: issues, weeks, months
2. Renew the subscription and notice that there are 3 input text boxes:
'number of num', 'number of weeks' and 'number of months'
3. Input a 'Number of weeks' value of 2
4. Query the subscription database table and notice that the value of 2
has been stored in the weeklength field for the subscription record you
just renewed
5. Apply the patch
6. Renew the subscription and notice that there is now a sublength
dropdown box containing issues, weeks and months
7. Set the month value to 3
8. Query the database and notice that 3 was stored in the monthlength
field for the subscription record
9. Create a new subscription and select the sub length values of issues
and 3
10. Query the database and notice that the numberlength field for the
subscription you just created is set to 3 showing that the sublength
dropbox is still working for creating a new subscription
Sponsored-By: Catalyst IT
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
At the moment noItemTypeImages pref controls staff and OPAC
display. With this patch, there will be a separate OpacNoItemTypes
preference that allows to control display of each separately.
To test:
- Apply patch and run database update
In Administration:
- Search for 'noItemTypes' preferences
- Verify the settings of both prefs match
- Toggle prefs, verify everything works ok
- Go to the item types configuration page
- Try different settings for both prefs:
- Both set to No: Only a message with a link to the prefs should show
- Both set to Yes or either set to Yes: image configuration options
should show
In the OPAC:
- Check the following pages with item-level_itypes = record
- advanced search
- detail page
- place hold page
- Check the following pages with item-level_itypes = item
- result list
- a list (opac-shelves)
- checkouts and overdues tabs in patron account
(Note: this didn't work right before, but will now.)
- reading history in patron account
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Calendars copy tool created duplicate values to database.
Holidays in target calendar weren't checked before
inserting new holidays. This patch fixes this.
To test:
1. Add holidays for branch A
2. Copy branch A calendar to branch B
3. Repeat copy to branch B
=> Check database, branch B has now duplicate holidays
4. Delete holidays from branches A and B
5. Apply patch
6. Repeat steps 1-3
=> Check database, no duplicates
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When MARC modification template actions are applied, they assume that
the from field is the same as the conditional field. This patch adds
checks for this, as well as tests to confirm the behaviour is correct.
CASE 1: Delete 1st field 020 if 651$z exists
BROKEN BEHAVIOUR (before patch): deletes the 2nd instance of 020 instead
of 1st
EXPECTED BEHAVIOUR (corrected by patch): deletes the 1st instance of 020
CASE 2: Delete 1st field 020 if 651$z matches Berlin. (must include '.')
BROKEN BEHAVIOUR (before patch): deletes the 2nd instance of 020
EXPECTED BEHAVIOUR (corrected by patch): deletes the 1st instance of 020
CASE 3: Delete field 020 if 650$2 does not match fast
BROKEN BEHAVIOUR (before patch): deletes all 020 fields even though
650$2 does match fast
EXPECTED BEHAVIOUR (corrected by patch): does not delete 020 fields
Confirm tests pass: t/db_dependent/MarcModificationTemplates.t
Sponsored-by: Catalyst IT
Signed-off-by: Frank Hansen <frank.hansen@ub.lu.se>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Otherwise the tests will fail. We will certainly log twice the error
when run from the UI, but not a big deal. This definitely needs more
attention in a follow-up bug report.
We want to raise proper exceptions here.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In some tests we want to know if we are in a testing environment.
When run the usual way, our trick works, the perl interpreter matches 'prove':
$ENV{_} eq 'prove'
In other situations, we have the KOHA_NO_TABLE_LOCKS environment variables, for the SendCirculationAlert race conditions (see bug 15854 and bug 18364).
For unknown reasons, Jenkins runs the tests with /usr/bin/perl.
This patch suggests to rename KOHA_NO_TABLE_LOCKS and use KOHA_TESTING
instead, when prove is not used (or not correctly detected as it it the
case for Jenkins)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
For the following SQL query:
INSERT INTO cities(city_name, city_country) VALUES ('Madrid', 'Spain'), ('Buenos Aires', 'Argentina');
We move from:
[ 'Madrid', 'Spain', 'Buenos Aires', 'Argentina' ]
to:
[ [ 'Madrid', 'Spain' ], [ 'Buenos Aires', 'Argentina' ] ]
Which make more sense to split, build and construct the queries
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The svc/members/search script is called in different places.
In some places (Set owner for a fund, add users to a fund, or set a
manager to a suggestion), we need patrons to be filtered depending on
the permissions they have.
For instance you can only set a fund's owner with a patron that has
acquisition.order_manage.
Currently we have fetching X (default 20) patrons, then filter them
depending on their permission.
Says you have 3 patrons that have the correct permissions but are not in
the 20 first patrons, if you do not define a search term, the search
result will be empty.
This is not ideal and we should filter when requesting the DB.
Test plan:
- Have more than 20 patrons, remove them their permissions
- Create 3 more:
1 superlibrarian
1 with the full acq permission
1 with acquisition.order_manage
- Create a fund and set a owner
- Search for patrons, without specifying a search term (to get them all)
=> Without this patch the new patrons you created are not displayed
=> With this patch they are!
Same test plan apply to set a manager to a suggestion (freshly pushed,
see bug 23590), with suggestions and suggestions.suggestions_manage
Note: The code has been written that way to rely on
C4::Auth::haspermission, but the SQL query is quite trivial and the gain
is important.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Owen Leonard 2018-03-16 10:47:47 UTC :
<<
I don't think the system preference adds any security. There are already multiple permissions required for working with plugins:
- Configure plugins
- Manage plugins ( install / uninstall )
- Use report plugins
- Use tool plugins
And even with those permissions your server must be configured to allow the use of plugins.
>>
Test plan :
1) Install kitchen sink plugin https://github.com/bywatersolutions/koha-plugin-kitchen-sink
2) Run misc/devel/install_plugins.pl
3) Set config enable_plugins=1
4) Check all parts of the plugin are working
5) Set config enable_plugins=0
6) Check all parts of the plugin are disabled
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In order to get the default value defined at DBMS level, we use
Koha::Reports (to inherit from Koha::Object->store) from the 2 add/edit
methods of C4::Reports::Guided.
A second step would be to remove completely those CRUD subroutines and
use directly Koha::Reports instead.
Test plan:
1. Add and edit some reports
2. Disable memcached, create a report, edit it
=> Should not crash
3. Make sure the tests make sense and that they pass after the second
patch.
The error was:
DBD::mysql::db do failed: Column 'cache_expiry' cannot be null [for
Statement "UPDATE saved_sql SET savedsql = ?, last_modified = now(),
report_name = ?, report_group = ?, report_subgroup = ?, notes = ?,
cache_expiry = ?, public = ? WHERE id = ? "] at
/kohadevbox/koha/C4/Reports/Guided.pm line 633.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ablity to specify a cash register id to link to
payments taken via SIP2 clients.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When "reserve/request.pl -> C4/Reserves.pm::IsAvailableForItemLevelRequest" called many times with hundred of items and "on shelf holds" parameter set to "If all unavailable" for these items + patron, it goes slow.
It happens because in subloop it is checking if all items available so it is O(n^2) and it re-checks each time the same info for each item with repeating DB/data requests.
Fix:
The inner loop 1:1 picked out into separate subroutine and called outside of the loop, saving data in 'items_any_available' variable once, this variable passed to IsAvailableForItemLevelRequest to be used inside as the precalculated result.
This made algorithm O(n) instead of O(n^2) so there is noticeable speed increase.
How to reproduce:
1) on freshly installed kohadevbox create/import one book,
remember that biblionumber for later use it in down below,
2) add 100 items for that book for some library,
3) find some patron, that patron's card number we will
use as a borrower down below to open holds page,
4) check for the rule or set up a single circulation rule
in admin "/cgi-bin/koha/admin/smart-rules.pl",
that rule should match above book items/library/patron,
check that rule to have a non-zero number of holds (total, daily, count) allowed,
and, IMPORTANT: set up "On shelf holds allowed" to "If all unavailable",
("item level holds" doesn't matter).
5) open "Home > Catalog > THAT_BOOK > Place a hold on THAT_BOOK" page
("holds" tab), and enter patron code in the search field,
or you can create a direct link by yourself, for example, in my case it was:
/cgi-bin/koha/reserve/request.pl?biblionumber=4&findborrower=23529000686353
6) it should be pretty long page generation time on old code, densely increasing for every hundred items added. In the case of this solution, it's fast, and time increases a little only, linear.
I tested on my computer in VirtualBox for page generation times,
did 3-5 runs for same case to check if results are stable, and got such values:
(old code):
100 items: 50 seconds
200 items: 3.2 minutes
300 items: 7.3 minutes
(version with fix):
100 items: 4.4 seconds
200 items: 7.5 seconds
300 items: 10.4 seconds
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>