The loop through the `_order_by` query parameter occurences introduced
by this patchset was naive regarding the possible scenarios.
When there's only one parameter passed, it shouldn't be expecting an
arrayref, but a scalar. This patch deals with that in the simplest way.
To test:
1. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/REST/Plugin/Objects.t
=> FAIL: Tests are failing
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass!
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
* Create 3 agreements, agreement #1 named 'a', agreement #2 named 'c' and agreement #3 named 'b'.
* Go to agreements list, click the Name column header, notice how the agreements get sorted by id #, not by first char in name. Expected order would be abc or cba, but it's acb or bca.
* Apply patch, on k-t-d, run the following if you're not using 'yarn js:watch':
yarn js:build
* Sort the list again on the 'name' column, notice how it now sorts alphabetically as expected, either abc or cba.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It would be very useful to have direct access to dt_from_string in our templates. This would allow for us to handle custom date and time formatting. It would, for example, allow us to output the month name for a given date via Template Toolkit easily.
Test Plan:
1) Apply this patch
2) In a notice add '[% Use KohaDates %][% KohaDates.datetime_from_string().ymd %]' to the top of a notice
3) Generate that notice for a patron
4) Note today's date in iso format is rendered at the top of the notice
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
-1 Log in to the staff client as a user who has Acquisition management (acquisition) permissions but not the stage_marc_import (tools) permission.
-2 Go to Acquisitions and Add to a basket.
-3 Select 'From a new file'
-4 You will be logged out as the user does not have percussion to visit that page.
-5 Apply patch
-6 Try again, you will not see the link for 'From a new file' if you don't have the permssion.
-7 Give the user the stage_marc_import, you will now see the link
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Even the POD name wasnt changed after copying :)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This could be extended later in bug 32968 to pass the permission of the
logged in user.
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When editing an existing holiday and checking the
"copy to all libraires" checkbox, the other calendars won't
get updates. Allow this by first checking if holiday exists
in target calendar and if not, add it.
To test:
1. Add unique holiday to branch A.
2. Don't check checkbox "Copy to all libraries".
3. Save.
4. Verify the holidays shows on all calendars as
a green box.
5. Edit the holiday, now check "Copy to all libraries"
and save.
=> Verify nothing has changed in other calendars:
only the green box, no holiday in list on the right
6. Edit again, make a change to description,
check checkbox, save.
=> Verify it's still not showing in the other
calendars.
9. Apply this patch.
10. Edit holiday again, check "Copy to all libraries"
and save.
=> Verify holiday is now added to other calendars.
11. Edit again, this time do not copy and save.
=> Verify holiday was edited just in branch A.
12. Again edit, check and save.
=> Verify holiday was edited in all libraries.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This includes Jonathan's followup
If cronjobs/fines.pl is running during circulation hours, then an issue may
be considered for having it's overdue fine updated after the issue has been
returned and it's fine status flipped from 'UNRETURNED' to 'RETURNED'. In
this case UpdateFine will create a duplicate fine because it can't find the
specific accountline for the (formerly) overdue issue.
This changes cronjobs/fines.pl to double check the issue before updating
the fine. If the issue has changed between starting the script and updating
the fine, then the script will skip it.
There is a small amount of time between the check and calling UpdateFine
where the issue can be changed and this problem can reoccure. The chance
of that happening is so small that it's probably fine to leave as is.
It is also possible that the fine won't be updated because the issue was
returned. In this case the fine payed by the patron will be lower, but that
is better then the patron finding later that there is more to a fine they
thought they had paid all of.
Test plan (by Caroline):
0. Preliminary settings
0.1. finesMode system preference must be set to Calculate and charge
0.2. There must be a circulation rule that will charge fines (beware of bug 32271)
0.3. In Tools > Calendar, today must not be a holiday
1. Make a lot of overdue checkouts - I used the batch checkout feature, but if your system already has a lot of overdue checkouts, you can skip to step 2
1.1. Enable batch checkouts
1.1.1. Go to Administration > Global system preferences
1.1.2. Search for BatchCheckouts
1.1.3. Set BatchCheckouts to Allow
1.1.4. Select all categories in BatchCheckoutsValidCategories
1.1.5. Click "Save all Circulation preferences"
1.2. Get a list of barcodes
1.2.1. Go to Reports
1.2.2. Click "Create from SQL"
1.2.3. Give the report a name
1.2.4. For the SQL query, enter
SELECT barcode FROM items WHERE onloan IS NULL LIMIT 60;
1.2.5. Click "Save report"
1.2.6. Click "Run report"
1.2.7. Click "Download" > "Tab separated text"
1.3. Go to a patron's file
1.3.1. Go to Patrons
1.3.2. Click on "Search"
1.3.3. Click on a patron's name
1.4. Do a batch checkout with a due date in the past
1.4.1. Click on the "Batch check out" tab on the left
1.4.2. In "Use a file", click "Choose file"
1.4.3. Choose the file downloaded from the report
1.4.4. In "Hard due date", choose a date in the past
1.4.5. Click "Check out"
1.4.6. Click "Checkout or renew"
2. Find the last issue in the database
2.1. In the database (or in reports), type the following query
SELECT issues.*, items.itype as itemtype, items.homebranch, items.barcode, items.itemlost, items.replacementprice, items.biblionumber FROM issues LEFT JOIN items USING (itemnumber) WHERE date_due < NOW() \G;
2.2. Copy the barcode from the last entry
3. Set up so that you can run fines.pl and check in the item at the same time (or very close to the same time)
3.1. In Koha, click the "Check in" option in the search bar at the top of the page
3.2. Paste the barcode in the search bar BUT DO NOT PRESS ENTER OR THE ARROW RIGHT AWAY
3.3. In a terminal, enter the fines.pl command
./misc/cronjobs/fines.pl
3.4. Execute the command and immediately click on the arrow in the staff interface to check in the item
4. Check the patron's fines
4.1. Click on the patron's name in the check in screen
4.2. Go to the Accounting tab on the left
4.3. In the search box just above the table, paste in the returned item's barcode
--> Without the patch, there are two fines, one Fine (Accruing) and one Fine (Returned) for the same item at the same time
--> With the patch, there is only one fine, Fine (Returned)
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This uses the new relationship from bug 33493 to fetch the transfers for items
To test:
1 - Transfer some items on a bib
2 - View the biblio details page in the staff interface
3 - Apply patch
4 - Confirm the view is the same
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adjusts the detail page to fetch items and host items
together, and prefetches transfers and checkouts
To test:
1 - Enable easy analytics
2 - Attach some items to a bib
3 - Checkout an item on the bib
4 - View the details page
5 - Apply patch
6 - View details page, confirm nothing has changed
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an option to the $biblio->items method to allow
retrieving the items and analytic items for a record. This is intended
to allow fetching a single Items object, and related object, rather than
having to fetch the items, and the host items, and push them together
This is step towards being able to fetch items using API/DataTables directly
To test:
1 - prove -v t/db_dependent/Koha/Biblio.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This will only have effect on installations running OPAC and staff
on the same domain name. In that case an OPAC cookie still allows
you to access intranet, and v.v.
Test plan:
Repeat the following steps WITHOUT this patch and WITH it.
Login via OPAC.
Go to staff. Perform an action that logs the interface in e.g. the
statistics table, like a checkout.
Inspect interface in the corresponding table. Observe difference
that this patch makes.
With this patch:
Run t/db_dependent/Auth.t. Should pass again.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Björn Nylén <bjorn.nylen@ub.lu.se>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run t/db_dependent/Auth.t without second patch.
Should fail:
# got: 'opac'
# expected: 'intranet'
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Björn Nylén <bjorn.nylen@ub.lu.se>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This bug adds the ability to define a list of item types that are blocked from being issued at that SIP account
To test:
1) Apply this patch
2) Visit Administration->Item types and select edit on the music item type
3) Make the rental charge 0 and save changes (this allows for the item to be checked out via SIP)
4) In the terminal, vim /etc/koha/sites/kohadev/SIPconfig.xml
5) Edit the term1 account and add the following *inside* the login section:
blocked_item_types="BK|MU"
You should have something similar to this: <login id ="term1" ........... checked_in_ok="1" blocked_item_types="BK|MU" />
6) Restart SIP (sudo koha-sip --restart <instancename>)
7) Run a checkout query for an item with the item type book. Here is an example you could use:
perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL --patron 23529001000463 --item 39999000011418-m checkout
8) Notice the checkout failed and you are given the screen msg "Item type cannot be checked out at this checkout location"
9) Run a checkout query for an item with the item type music. Here is an example you could use:
perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL --patron 23529001000463 --item 39999000008715 -m checkout
10) Notice the checkout failed and you are given the screen msg "Item type cannot be checked out at this checkout location"
11) vim /etc/koha/sites/kohadev/SIPconfig.xml and delete the BK from the blocked_item
12) Delete the BK from blocked_item_types. It should now look like :
blocked_item_types="MU"
13) Restart SIP (sudo koha-sip --restart <instancename>)
14) Run a checkout query for the item with the item type book
perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL --patron 23529001000463 --item 39999000011418 -m checkout
15) Checkout succesful
16) Run a checkout query for the item with the item type music
perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL --patron 23529001000463 --item 39999000008715 -m checkout
17) Still fails (because it is blocked)
18) prove t/db_dependent/SIP/Message.t
19) Congratulate yourself for making it through the long test and sign-off :)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
prove t/db_dependent/SIP/Message.t
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run t/db_dependent/Breeding.t
Run t/db_dependent/Breeding_Auth.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Amended patch: perltidy
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The array serverhost is not filled. Should be replaced with values
from servers array.
Test plan:
Nothing exciting here. Read the patch.
Note that we will test in the next patch if the hostname is saved
correctly in the import batch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
[1] If you have access to a Z3950 MARC8 auth server, search
for an authority record and import it.
[2] If you have access to a Z3950 UTF8 auth server, search
for an authority record and import it.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
At some point in the patch series we lost the availability api schema.
This patch restores a basic version, but we should work towards a
clearer enum based schema for each of the available blockers, confirms
and warnings.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Our consistency improvement to the AddIssue return in bug 23336
highlighted a bad test assumption. The 'Reinsert the original issue'
line was silently failing and as such the subsequent test lines were
actually resulting in a renewal (which previous to this patchset
returned an empty return that happened to match the empty return of an
issue failure)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes a particular use case be handled correctly: i.e. no
context is passed (e.g. 'biblio' explicitly) and the query is done
against the `biblio_id` attribute. This results in the following DBIC
error:
[ERROR] GET /api/v1/biblios: unhandled exception (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Column 'biblionumber' in where clause is ambiguous at /kohadevbox/koha/Koha/Objects.pm line 394>>
With this patch, this is no longuer the case :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Since template variables cannot be processed by JS, we must use a
template to declare a JS variable which the JS file can used. This patch
corrects this problem in the JS file which handles display of the
authority MARC preview from the authority search results page.
To test, apply the patch and go to Authorities.
- Perform a search which will return multiple authority results.
- Click "Actions -> MARC preview." The preview should display correctly.
- Click "Actions -> MARC preview" on another search result. This preview
should also look correct.
- There should be no JavaScript errors in the browser console.
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We don't actually need the Clone import.. it's not used in Biblios.pmt
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In order to reduce the technical debt carried on the orders controller,
and to highlight the decisions made on the prior patch, I adapted the
list() orders controller using the new tools in town.
The result is this endpoint can now embed bibio, without needing to have
a custom piece of code.
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/*.t
=> SUCCESS: Tests pass :-D
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes biblioitem attributes be searchable on the biblios
endpoint. It does so by using the new method in Koha::Biblios, and by
adjusting objects.search(_rs) to accept a $query_fixer arrayref of
functions to be applied to each query or order_by parameters.
The result is cleaner code to write, but complex internals.
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/biblios.t
=> SUCCESS: Tests pass! Searching for biblioitem attributes works on the
API!
3. Sign off :-D
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the `api_query_fixer` method to the class, and adds
tests to validate its behavior.
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/Biblios.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Turn on NoIssuesChargeGuarantorsWithGuarantees and set the amount to 5.
2. Create a guarantor/guarantee relationship.
3. Add a manual invoice to the guarantor that is larger than 5.00.
4. Notice the message on that circulation ( check out tab ) page. " Charges: Patron's guarantors and their other guarantees collectively owe X. Checkouts are BLOCKED because fine balance is OVER THE LIMIT. "
5. Look at the moremember ( details ) page. The same message does not appear.
6. Apply patch, restart_all
7. Try step 5 again, the message should now appear.
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Typo patron_searh_js.
Note for QA/RM: Ignore this qa tools warning:
forbidden pattern: console.log (line 211)
This is an intended console warning.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Move patron search query logic out of patron_autocomplete into new function
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Remove patron-autocomplete.js file
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the patron search bar and pages to default search
method to that defined by DefaultPatronSearchMethod system preference.
Test plan
1) Prior to this patch confirm that regardless of what you set
DefaultPatronSearchMethod to, the search in /members/member.pl,
members/members-home.pl and the search from the patrons search top bar
all default to 'contains'.
2) Apply the patch
3) Confirm that the system preference now affects the default option for
match type upon page load.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan:
1) Set up your cash register
2) Take a payment
3) Void that payment
4) Verify the voided fee shows for the "All payments to the library" and
"Payment" transaction type filters
5) Apply this patch
6) Restart all the things!
7) Verify the voided fee no longer shows for the "All payments to the library" and
"Payment" transaction type filters
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch wraps the "Subscription details" link on the bibliographic
detail page with a permissions check, "CAN_user_serials," so that a user
lacking permission to access the Serials module will not be shown the
link.
To test, apply the patch and view the bibliographic detail page of a
serial record.
- When viewing the "Subscriptions" tab as a user with Serials
permissions you should see the "Subscription details" link.
- When viewing the tab as a user without the correct permissions the
link should not be present.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Not only additem suffers from it. We can do the same with serials-edit.
This patch adds a server-side and client-side check as we did for additem.
Test plan:
Receive serial with adding items.
Try to add more than 999 items in number of copies.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Try to add more than 3 characters now in the number of copies.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently hardcoded to 1000.
Can be refined later. Let's first prevent this kind of accidents.
Test plan:
Add additem.pl. Edit the 1000 to 2. Restart all.
Add 3 multiple copies. Notice that you got 2.
Revert your code change.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch introduces a public endpoint for cancelling holds.
Cancellation requests are generated when the hold is waiting and
configuration allows requesting cancellation, as the OPAC does right
now.
Tests cover all the use cases.
To test:
1. Apply this patches
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/patrons_holds.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Whenever we need to generate manually a new serial we go to page
'serials-edit.pl'. With this patch it is possible to generate a new
serial on page 'serials.pl'.
Test Plan:
-- Previously we need a serial which is in EXPECTED status & the Date
received should not be later than today --
1) On the intra. Make sure to have at least 1 subscription for a
bibliographic record & 1 vendor linked
2) Then Home > Serials > Claims > Claims for <your_vendor_name>
3) Tick the checkbox of the row where the status is EXPECTED then
4) Click 'Send notification'
5) Notice the status of the row : it is now CLAIMED
6) To verify: Home > Serials > Serial collection information for
<your_record_name>
7) Here the status is CLAIMED too but nothing happened around
8) Apply patch
9) Repeat from 2) to 6)
10) The status is still CLAIMED & the new serial with status EXPECTED is
freshly generated
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We're updating the side menu searchtype when the search header is submitted,
we should also update the searchtype in the search header when the form is submitted
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
