Tiny adjustment for very special and malicious cases needed in
Koha::SearchEngine::Elasticsearch::QueryBuilder::clean_search_term.
Extended unit tests added following Nick's suggestions in
Bug 33407 discussion.
Test plan
=========
1. Use ktd with Elasticsearch and ktd's test data.
2. Edit the 4th record (The C programming language) and add a semicolon
followed by a space before the slash in 245 $a to have:
The C programming language ; /
3. Make a search for the first ISBD zone taken verbatim from the forth
record:
The C programming language ; / Brian W. Kernighan, Dennis M. Ritchie
There should be no result.
4. Apply the patch, restart plack.
5. Repeat the search. You should get the record.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Some SUSHI providers return ServiceActive instead of the documented Service_Active:
https://countermetrics.stoplight.io/docs/counter-sushi-api/f0dd30f814944-server-status
This ensures the test connection does not fail regardless of what is used
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>
Add the ability to specify STOMP connection info via environment
variables and utilize those in unit tests.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes the background jobs (jobs from now on) connect step not
try to connect to the STOMP broker, unless explicitly told to do so.
This is achieved by using a newly introduced system preference
`JobsNotificationMethod` which falls back to STOMP if undefined.
The "about" page now has 3 states for
+ Message broker: Using SQL polling
+ Message broker: Using SQL polling (Fallback, Error connecting to RabbitMQ)
+ Message broker: Using RabbitMQ
The goal for this patch is to stop flooding the logs on very busy sites
when Rabbit is not being used. This shouldn't predate any efforts on
making the STOMP based jobs brokering mechanism solid and usable.
To test:
1. On clean `main`, run:
$ ktd --shell
2. Open the logs on a separate terminal:
$ ktd --shell
k$ tail -f /var/log/koha/kohadev/*.log
3. Stage some MARC for import
=> SUCCESS: No warnings about STOMP
4. Import the staged records
=> SUCCESS: No warnings about STOMP
5. Stop rabbitmq:
k$ sudo service rabbitmq-server stop
6. Repeat 2-4
=> FAIL: The logs say it couldn't connect to STOMP
7. Apply this patches and run:
k$ restart_all
8a. See the "about" page, should read:
Message broker: Using SQL polling (Fallback, Error connecting to RabbitMQ)
8b. Repeat 2-4
should work with one warning in the
9. Start rabbit:
k$ sudo service rabbitmq-server start
k$ restart_all (not really necessary)
10a. See the "about" page, should read:
Message broker: Using RabbitMQ
10b. Repeat 2-4
=> SUCCESS: No warnings about STOMP
11. Change the `JobsNotificationMethod` system preference to *polling*
and stop rabbit:
k$ sudo service rabbitmq-server stop
k$ restart_all
12a. See the "about" page, should read:
Message broker: Using SQL polling
12b. Repeat 2-4
=> SUCCESS: No warnings about STOMP, not even on startup
13. Sign off :-D
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
-Newly created or edited libraries no longer display 'null' for undefined
open and close times.
-Libraries without any defined hours will state such instead of displaying the
hours table.
-The CalendarFirstDayOfWeek system preferences is now respected when viewing
a library with defined hours.
-Time displays and inputs now follow the TimeFormat system preference.
-Times are no longer displayed with seconds.
As part of this patch, a new Template Filter, KohaTimes, has been added to
allow for proper formatting of time strings based on systems preferences.
To Test:
1. Login to staff interface
2. Go to Koha administration > Basic parameters > Libraries
3. Edit any library or create a new library. Do not set hours.
4. Save the library.
*Note that on the library list, in the hours column, all days are displayed
with 'null'.
5. Edit or create a 2nd library.
6. Try to manually enter a time (not using the flatpickr modal)
*Note that the mask wants a date format, not a time format.
7. Set some hours for the library, leaving at least one
day without hours. Save.
*Note that in the library list, in the hours column, defined times are in
the format HH:MM:SS.
7. Edit the system preference CalendarFirstDayOfWeek to set a day other
than Sunday as the first day of the week.
8. Return to Koha administration > Basic parameters > Libraries
9. Click on the name of a specific library with hours to view details.
*Note that the order of the calendar weeek still starts with Sunday.
10. The order of the calendar week still starts with Sunday.
11. Edit the system preference TimeFormat and set to 12-hours.
12. Return to Koha administration > Basic parameters > Libraries.
*Note that the time format on the branches list is not in 12-hour format.
13. Click on the name of a specific library with hours to view details.
*Note that the time format in the branch details screen is not in 12-hour
format.
14. Apply Patch.
15. Return to Koha administration > Basic parameters > Libraries
16. Verify that your library with all undefined times shows "Library hours
not set".
17. Verify that your library with defined hours is showing times in HH:MM
format, and days without defined hours are blank.
18. Verify that your library with defined hours is respecting the TimeFormat
preferences.
19. Click on the name of a library with hours to view details.
20. Verify that the hours respect the CalendarFirstDayOfWeek and TimeFormat
preferences.
21. Click on the name of another library without hours to view details.
Verify these libraries show as "No opening hours have been set"
in the branch detail view.
22. Edit a library's hours. When inputing, try to manually enter a time (not
using the flatpickr modal). Verify that you can enter time in the proper
(12 or 24 hours) format.
Sponsored-by: Westlake Porter Public Library
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
After Bug 33496, host items are displayed even when system preference EasyAnalyticalRecords is disabled.
Test plan :
1) Build an analytical record with 773$0 and $9
2) Enable 'EasyAnalyticalRecords'
3) Go to catalogue details page
=> You see the linked item
4) Disable EasyAnalyticalRecords
5) Go to catalogue details page
=> You dont see the linked item
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 patch only fixes price rounding by using Math::BigFloat.
To test:
0) Enable syspref OrderPriceRounding
1) Create an order line in acquisitions with vendor price 18.90 and a
discount of 5 %.
2) Verify that the total (tax excl.) in the order table on the basket
page is 17.95.
3) Apply the patch.
4) Reload the basket page.
5) Verify that the total (tax excl.) in the order table on the basket
page now is 17.96, which is correct.
6) Run: prove t/Number/Price.t
Sponsored-by: Karlsruhe Institute of Technology (KIT)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1) Apply test patch only. Run:
prove t/db_dependent/Koha/BackgroundJob/ErmSushiHarvester.t
2) Verify tests fail.
3) Apply this patch. Run tests again. Verify they pass.
PA amended: Added test plan
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The SUSHI provider in question for this patchset also does not return any
Report_Items entry. This patch accounts for that.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When fixing the issue around the missing platform parameter, we
noticed this particular provider also returns 'Exceptions' as
its own thing, not part of 'Report_Header', despite documentation:
https://countermetrics.stoplight.io/docs/counter-sushi-api/7cp0h7n1hm2en-tr-j1-journal-requests-controlled
From the link above, search for 'Exceptions'. Notice it should be under 'Report_Header'.
Either way, this patch accounts for this possibility.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
1) Apply only test patch for case 1. Run tests:
prove t/db_dependent/Koha/BackgroundJob/ErmSushiHarvester.t
2) Verify tests fail. Apply the other patch for case 1.
3) Run tests again. Verify they now pass.
4) Repeat the test plan but using patches for case 2
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This ensures that SUSHI errors, if present, are shown on the UI even if
response->code >= 400.
This means that if, for example, SUSHI provider returns 401 with SUSHI
error like so:
{"Code": 2020, "Severity": "Error", "Message": "API Key Invalid"}
Then, the 'API Key Invalid' will be shown to the user, without having to
check logs.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Set pref ReportsExportLimit to some positive integer.
Test if exporting a report respects that limit.
Run t/db_dependent/Koha/Reports.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch reverts the change to request_transfer, opting to tackle the
StockRotationAdvance requirement to stay in place in ModItemTransfer
itself.
We also add a FIXME to RotatingCollections.. I'll look to removing that
on another bug to reduce the scope of this one.
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>
1) Don't automagically always set a transfer to in transit on checkin..
wait for the user to actually confirm that's the case
2) New transfers triggered by a hold should take precidence, so hide
transfers for any other reason from display
3) Update get_transfer and get_transfers to ensure ordering isn't lost
when prefetch is used and add tests for this
Signed-off-by: Nick Clemens <nick@bywatersolutions.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>
ModItemTransfer is still very heavy handed and outright overrules
existing transfers in the queue.
For StockrotationAdvance transfers it's important that they remain in
the queue to get actioned later, even if a higher precident transfer is
actions in the interim.
This patch adds a clause to the cancellation call within
request_transfer such that StockrationAdvance transfers are left in tact
for the next time the item is checked in.
Test plan
1) Item is added to stock rotation
2) The cronjob creates a 'StockRotationAdvance' transfer
3) The item is checked in, which initiates the transfer, however, a hold is triggered
4) The hold is confirmed, which replaces the StockRotationAdvance
5) The item is checked out
6) The item is checked in, which initiates the transfer again
7) The item is checked in at it's destination and the StockrotationAdvance transfer
has the proper date arrived date set.
Signed-off-by: Nick Clemens <nick@bywatersolutions.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>
Creation and Modification times are maintained by the database, but on
add/update we were not fetching the updated fields from the database for
the api response.
This patch corrects that and also updates the api schema to reflect that
these are readOnly fields.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It makes sense not to introduce mapping code if there's no reason for it.
Accordingly the the columns are now of type DATETIME instead.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Sticking to API guidelines, this adds the creation_date and
modification_date fields to the api definitions and the required
to_api_mappings for those fields to be properly populated.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This simple patch implements C4::Biblio::GetMarcControlnumber in the
right spot on the Koha::* namespace.
To test:
1. Apply this patches
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/Biblio/Metadata/Extractor/MARC.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If a bib record is hidden by OpacHiddenItems,
mark it as deleted in the OAI-PMH, so that it's metadata
is not consumed in a new OAI-PMH harvest, and it's marked
for removal if the metadata was consumed in previous harvested.
Test plan:
0. Setup
vi /etc/koha/sites/kohadev/oai.conf
format:
marcxml:
metadataPrefix: marcxml
metadataNamespace: http://www.loc.gov/MARC21/slimhttp://www.loc.gov/standards/marcxml/schema/MARC21slim
schema: http://www.loc.gov/MARC21/slimhttp://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd
include_items: 1
Set sysprefs:
OAI-PMH: Enable
OAI-PMH:ConfFile: /etc/koha/sites/kohadev/oai.conf
OAI-PMH:AutoUpdateSets: Enable
OAI-PMH:AutoUpdateSetsEmbedItemData: Enabled
OpacHiddenItems:
barcode: [3999900000001]
OpacHiddenItemsHidesRecord: Hide
Adminsitration->OAI set configuration->New set
Choose anything for setSpec and setName
On new set: Actrion->define mappings
Field: 952
Subfield: p
Operator: is equal to
Value: 3999900000001
perl misc/migration_tools/build_oai_sets.pl -r -v -i
1. koha-plack --restart kohadev
2. Go to http://localhost:8080/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=marcxml
3. Confirm KOHA-OAI-TEST:1 is marked as deleted and not metadata visible
4. Go to http://localhost:8080/cgi-bin/koha/oai.pl?verb=ListIdentifiers&metadataPrefix=marcxml
5. Confirm KOHA-OAI-TEST:1 is marked as deleted
6. Go to http://localhost:8080/cgi-bin/koha/oai.pl?verb=GetRecord&metadataPrefix=marcxml&identifier=KOHA-OAI-TEST:1
7. Confirm record is marked as deleted and no metadata visible
8. View Sets and confirm the record appears in the set but as deleted record
9. Change OpacHiddenItemsHidesRecord syspref to "Don't hide" and repeat above steps
10. Confirm that the record metadata is now visible and the record is not marked as deleted
Signed-off-by: Jake Deery <jake.deery@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Renewals or automatic renewal attempts can change the timestamp of an issue and cause a sort
on this field to functionally randomize the order of checkouts returned.
Prior to bug 19935 the GetPendingCheckouts routine returned items in issuedate order.
Removing the sort on timestamp will return the previous behaviour and provide a more predictable sorting
To test:
1 - Checkout some items to a patron
2 - Print a checkout slip - items are in the order they were checked out
3 - Renew an item,print the slip again it is now at the top of the list
4 - Apply patch, restart_all
5 - Print slip again - the items are now ordered in the order they were checked out.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patchset makes:
* The EmailFieldPrimary value 'OFF' be replaced by an empty string
* Koha::Patron->notice_email_address() handle the empty case more
gracefully
To test:
1. On main, manually set the EmailFieldPrimary syspref to empty
$ ktd --shell
k$ koha-mysql kohadev
> UPDATE systempreferences SET value='' WHERE variable='EmailFieldPrimary';
2. Enable `AutoEmailNewUser`
3. Create a new user
=> FAIL: Koha explodes like:
```
The method Koha::Patron-> is not covered by tests!
Trace begun at /kohadevbox/koha/Koha/Object.pm line 992
Koha::Object::AUTOLOAD('Koha::Patron=HASH(0xaaaae37ac550)') called at /kohadevbox/koha/Koha/Patron.pm line 1662
Koha::Patron::notice_email_address('Koha::Patron=HASH(0xaaaae37ac550)') called at /kohadevbox/koha/members/memberentry.pl line 448
...
4. Apply this patches
5. Run:
k$ updatedatabase
=> SUCCESS: Update succeeds
6. Restart all and retry creating a patron
=> SUCCESS: It worked!
7. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan
1. Go to the staff client
2. Go to administration
3. Search systempreferences for 'StaffInterfaceLanguages'
4. Ensure there is a systempreference variable matching 'StaffInterfaceLanguages'
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nicolas Hunstein <nicolas.hunstein@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We were adding "XXX" that was replaced with "999" before the move to the atomic update files (bug 13068).
We do no longer need this code.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There are several things going on here.
The tests are failing randomly when some additional class sources are in the
DB. This should never happen on Jenkins, but it happened, see the third
patch of this patch set (spoiler: tests not run within a txn)
There were also a sorting problem: by default sort will show
uppercases first:
A, B, C, a, b, c
However we want:
a, A, b, B, c, C
which is what fc does (https://perldoc.perl.org/functions/fc)
Test plan:
0. Checkout the main branch, without patches from this patchset.
1. Run t/db_dependent/ClassSources.t several times
=> Notice that new entries in the DB table 'class_sources' are created
2. Run t/db_dependent/Koha/UI/Form/Builder/Biblio.t and
t/db_dependent/Koha/UI/Form/Builder/Item.t
=> They fail (if not, run t/db_dependent/ClassSources.t again)
3. Apply the patches
4. Run t/db_dependent/ClassSources.t
=> No more additional entries in DB, tests are correctly run within
transactions
5. Run t/db_dependent/Koha/UI/Form/Builder/Biblio.t and
t/db_dependent/Koha/UI/Form/Builder/Item.t several times
=> They always pass
Note that the sort should actually be done on the description, not the
code. But that's for another bug...
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Not directly related to the failure, only a bit of cleaning before
starting.
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This adds a unit test for the new preparation_period handling introduced
into the find_booking method of Koha::Item.
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch ensures we catch checkouts that would interfer with the
preparation period set for an existing booking by adding said period to
the bookings search.
We also reduce the proposed due date for the checkout to be confirmed by
the preparation period for the item.
Test plan
1) Set a booking preparation period for an itemtype
2) Add a booking for an item with that itemtype to fall beyond the due
date that the item would be assigned if you were to check it out now
to your test user, but within the number of days you've set for your
preparation period.
3) Attempt to check the item out to your test user.
4) Note that we catch the booking and warn and that the latest return
date suggested take the preparation period into account.
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: Kristi Krueger <KKRUEGER@cuyahogalibrary.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Use of uninitialized value in numeric eq (==) at /kohadevbox/koha/Koha/Patron.pm line 446.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If the database version and the code version are the same, we should
short circuit and exit immediately.
This patch adds the Koha::Installer module which can very quickly
check if a db or atomic update is needed.
It also moves the logic for C4::Installer::TransformToNum to
Koha::Installer::TransformToNum for performance reasons.
It also moves the logic for C4::Installer::get_atomic_updates to
Koha::Installer::get_atomic_updates for performance reasons.
Test plan:
1. Apply patch
2. Run `time koha-upgrade-schema kohadev`
3. Note that it completes in less than .1 seconds
4. To test db updates, change the database Version to a number
slightly behind the code version, and run
`time koha-upgrade-schema kohadev`
5. Note that the correct version update is processed
6. To test atomic updates:
cp installer/data/mysql/atomicupdate/skeleton.pl \
installer/data/mysql/atomicupdate/bug_34088.pl
7. Run `time koha-upgrade-schema kohadev`
8. Note that it takes over 1 second to run and the atomic update
is attempted
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch refactors some small pieces of code to use the helpers as
prescribed on our coding guidelines [1] instead of manually crafting
responses.
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/
=> SUCCESS: All tests pass
3. Sign off :-D
[1] https://wiki.koha-community.org/wiki/Coding_Guidelines_-_API#REST4:_Controller_code_.5BDRAFT.5D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the `usage_count` method to be used for embedding from
the API. Tests cover all use cases.
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/RecordSource.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
I generally push for contextual use of accessors in TT notices and try
to reduce extra lookups.
In this case we can access the pickup library branchname directly using
the pickup_library relation available to us in the booking object we
pass.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the logic to pass the object to be deleted through to
GetPreparedLetter.
This way, as we add fields and accessors to the object in the future,
they will automatically become available to the notices.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When a booking is cancelled, patron received an email based on specific
letter.
Test plan:
1) Create a letter with code "BOOKING_CANCELLATION" on "Notices and
slips" tool.
2) Add booking or go on item already booked in advance.
3) Cancel it
4) Verify in message_queue table directly or go on patron page and click
on "Notices" tab section.
Sponsored by: Association de Gestion des Œuvres Sociales d'Inria (AGOS)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch corrects two instances of RESERVED_WAITING to RESERVE_WAITING
Test plan:
1) Navigate to system preferences and search for AllowItemsOnHoldCheckoutSCO
2) Observe from the description that the correct status code is RESERVE_WAITING
3) Search the repository for RESERVED_WAITING - you should find two instances, one in Checkouts.pm and one in checkout.js
4) Apply patch
5) Repeat step 3 - there should be 0 instances
Signed-off-by: Lucas <lchirlias@ville-roubaix.fr>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>