Update the preference name from 'Borrower' to 'Patron' and correct
spelling of receive.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The language used in the syspref preferences was a bit confusing.
Also, it makes sense to keep these two together on the page as they
are intrinsically linked.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATCH and restart all
2. Run the update_localuse_from_statistics.pl script without a confirm flag, nothing happens.
3. Run the script and add the --confirm flag, stuff happens.
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Under some circumstances (e.g. non-standard disk latency) po files fail
to be generated. The output from the gulp po:update --lang xx-XX task
is than like this:
[10:01:39] 'po_update_staff' errored after 6.41 s
[10:01:39] Error: ENOENT: no such file or directory, open '/tmp/koha-5WCc9s/Koha-staff-prog.pot'
This is due to the time dependencies inside the function flush (callback)
(in the function xgettext) in gulpfile.js. It happens that the
/tmp/koha-NNNNNN folder gets deleted before the asynchronous callback
function called by fs.readFile is completed. The callback should copy
the content of the .pot file from /tmp/koha- to its final destination,
while, in parallel in fact, the folder inside /tmp is being removed.
This creates a race condition.
Test plan:
==========
Hard to reproduce. But the race condition found in the code should
be obvious.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Removing the manual transfer and rightaway doing the Reserve
transfer. One test description was misleading too.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Not used? Dont import.
Which actually only leaves circ/waitingreserves.pl as the only
'real' caller.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
GetOtherReserves attempts to set the waiting/transit status for the next
hold on the list when applicable, but in practice it either leaves the
hold state unchanged, or sets the itemnumber without setting the found
status (erroneously converting bib-level holds to item-level holds).
The latter situation only occurs when the user has been prompted to
confirm, cancel, or revert the hold, and is able to ignore the prompt.
In those situations, the hold's state should not change.
GetOtherReserves does not need to change the hold state, and it does not
do so correctly. Besides that, it does not do much other than call
CheckReserves, and is only used in 3 places.
This patch removes GetOtherReserves, and refactors returns.pl and
C4::Reserves::ModReserveCancelAll to call CheckReserves directly instead.
To test:
1. Place 2 bib-level holds for 2 different patrons (Patron A and Patron
B) on the same record, both for pickup at the logged-in library
2. Check in an item from that record to fill Patron A's hold
3. Set the hold's expiration date to yesterday by accessing the database
in the command line:
- In a ktd shell prompt, open the db client with koha-mysql kohadev
- UPDATE reserves
SET expirationdate = DATE_SUB(CURDATE(), INTERVAL 1 DAY)
WHERE borrowernumber = <Patron A's borrowernumber>
4. Go to Circulation > Holds Awaiting Pickup, and find the hold in the
"holds waiting past their expiration date" tab
5. Click the "Cancel hold" button in the Actions column next to the hold
(do not check in the book)
6. Return to the bib record and look at Patron B's hold
--> Note that Patron B's hold is now an item-level hold and does not
have a waiting status
7. Cancel Patron B's hold
8. Place 2 new holds on the record: one for Patron A at the logged-in
library, and one for Patron B at a different library
9. Check in an item to fill Patron A's hold
10. Repeat steps 3-5 to expire and cancel Patron A's hold
11. Return to the Holds tab of the bib record and look at Patron B's hold
--> Note that Patron B's hold is now an item-level hold, and there is no
"Revert transit status" button
12. Place 2 bib-level holds for 2 different patrons (Patron A and Patron
B) on the same record, both for pickup at the logged-in library
13. Check in an item from that record to fill Patron A's hold
14. Check in the same item again. A modal will pop up, saying that the
hold is already waiting
15. In the modal, choose a cancellation reason and click "Cancel hold"
--> A new modal will pop up to fill Patron B's hold
16. Click "Ignore" on the modal for Patron B's hold
17. Return to the bib record and look at Patron B's hold
--> Note that Patron B's hold is now an item-level hold and does not
have a waiting status
18. Apply patch
19. Repeat steps 1-6
--> Note that Patron B's hold is still a bib-level/"next available" hold
20. Repeat steps 7-11
--> Note that Patron B's hold is still a bib-level/"next available" hold
21. Repeat steps 12-17
--> Note that Patron B's hold is still a bib-level/"next available" hold
Make sure correct behavior is unchanged:
22. Cancel Patron B's hold
23. Place 2 new holds on the record: one for Patron A at the logged-in
library, and one for Patron B at a different library
24. Check in an item from that record to fill Patron A's hold
25. Check in the same item again. A modal will pop up, saying that the
hold is already waiting
26. In the modal, choose a cancellation reason and click "Cancel hold"
--> A new modal will pop up to fill Patron B's hold
27. Click "Print slip, transfer, and confirm" on the modal for Patron B's hold
--> Confirm that the information on the slip is correct
--> Confirm that the hold is correctly put in transit
22. Set HoldsAutoFill and HoldsAutoFillPrintSlip to "Do"
23. Place a bib-level hold for the logged-in library
24. Check in an item from that bib
--> Confirm the information on the slip is correct
--> Confirm the hold is correctly assigned and set to waiting
25. Place a bib-level hold for a different library
26. Check in an item from that bib
--> Confirm the information on the slip is correct
--> Confirm the hold is correctly put in transit
27. Change the logged-in branch to match the hold pickup location
28. Check the item in
--> Confirm the information on the slip is correct
--> Confirm the hold is correctly assigned and set to waiting
29. Repeat steps 22-26
--> Confirm a correct hold slip pops up for Patron B's hold
--> Confirm that Patron B's hold is correctly put in transit
30. Cancel Patron B's hold
31. Place 2 bib-level holds for 2 different patrons (Patron A and Patron
B) on the same record, both for pickup at the logged-in library
33. Repeat steps 24-26
--> Confirm a correct hold slip pops up for Patron B's hold
--> Confirm Patron B's hold is correctly set to Waiting
34. Prove t/db_dependent/Circulation.t
35. Prove t/db_dependent/Koha/Holds.t
--> Tests pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Apply this patch only
2. prove t/db_dependent/Koha/Holds.t
--> Tests pass
3. Apply the other patch
4. prove t/db_dependent/Koha/Holds.test
--> Tests still pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
A Marcel's QA patch to Bug 36552 added use POSIX; in two spots.
In https://metacpan.org/pod/POSIX we read:
CAVEATS
Everything is exported by default (with a handful of exceptions). This is
an unfortunate backwards compatibility feature and its use is strongly
discouraged. You should either prevent the exporting (by saying use
POSIX ();, as usual) and then use fully qualified names (e.g.
POSIX::SEEK_END), or give an explicit import list. If you
do neither and opt for the default (as in use POSIX;), you will
import hundreds and hundreds of symbols into your namespace.
This patch fixes this.
No test plan.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We must list the columns, or the db rev will fail when a new column is
added. It happened here when 33478 added 'style'
Also remove id and dates
To test:
1. On current main, run:
$ ktd --shell
k$ perl /kohadevbox/misc4dev/run_tests.pl --koha-dir=. --run-db-upgrade-only
=> FAIL: Tests explode for DB query issues
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass!
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
In Elasticsearch, the field 041 (subfields: a, d, e, i, j)
is not indexed with 'ln' search field. As a result, records cannot
be found when searching with languages present in 041 (but only
with the one from 008/35-37), and the languages are also missing
from the facet.
Subfields content (only relevant subfields):
$a - Language code of text/sound track or separate title
$d - Language code of sung or spoken text
$e - Language code of librettos
$i - Language code of intertitles
$j - Language code of subtitles
Test plan
=========
0. Have a test installation with Elasticsearch.
1. In ktd with its test data, make a biblio search for a language present
in 041 a/d/e/i/j but not in 008/35-37, e.g. for Japanese (with ln:jpn
or from Advance search). You will get no results.
2. Apply the patch, reindex with:
sudo koha-elasticsearch --rebuild -r -b kohadev
3. Repeat the test. You should get some records and also you should see
the Japanese language in the Languages facet.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch simply add the 'strong' class to the assignee label in the
catalog concerns display ticket modal.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes corrections to OPAC CSS to address two small issues.
To test, apply the patch and rebuild the OPAC CSS.
- Perform a catalog search which will return multiple results..
- In the table of search results, check the icon and text for the
controls under each title: "Place hold", "Add tag", "Add to cart" etc.
- The colors should be consistent, with a slightly darker blue for the
icons.
- Scroll down until the table header "sticks" to the top of the
viewport.
- There should be no gap between the header row with the pagination
links and the row with the "Select all", "Clear all", etc. controls.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATCH
2. Set CircConfirmItemParts to 'Require'.
3. Add a materials specified message to an item. ( 952$3 )
4. Add the following CSS to your IntranetUserCSS:
.mats_spec_label { color: white; background: purple; }
.mats_spec_message { color: white; background: green; }
5. Checkout that item. Notice the message should be green and the label (Note about the accompanying materials:) should be purple.
6. Check in that item. Notice the message should be green and the label (Note about the accompanying materials:) should be purple.
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a 'needsconfirm' class and a unique class to each NEEDSCONFIRM message on circ/circulation.tt to make these easier to style individually.
To test:
1. APPLY patch
2. Review the diff to see each of the NEEDSCONFIRMATION messages.
3. Add some CSS to IntranetUserCSS like this:
.needsconfirm { padding: 1em; color: #fff; }
.reserved { background: blue; }
.debt { background: red; }
.reserve_waiting { background: orange; }
.rentalcharge { background: purple; }
.renew_issue { background: limegreen; }
4. Place a hold on an item for Patron A, do not trigger the hold, and check the item out to Patron B. The message background is blue.
5. Then check the item in, confirm the hold, then check the item out to Patron B. The message background is orange
6. Check something out that is already checked out to that patron, message background is lime green.
7. Have too much debt and check something out to a patron, message is red.
Note: There are plenty more NEEDSCONFIRMATION messages but I don't think we need to test every single one.
Note: These background colors are more testing purposes only.
Signed-off-by: Donna <donna@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
With Zebra, the general keyword search covered the entire record content,
even if the field was not explicitly indexed with a Zebra index (the Any index).
With Elasticsearch only the content of the fields explicitly indexed
can be found with general keyword search. This is OK, to some extent, but with
the current configuration it hides the content fo some important notes from the
searches, and librarians complained about that: 520 - Summary, etc.,
561 - Ownership and Custodial History, 563 - Binding Information.
This patch adds the content of 520, 561, and 563 fields to the 'note'
search field.
Test plan
=========
1. Have an installation with Elasticsearch.
2. Add some information to the 520, 561, and/or 563 fields (561 is
hidden in the default framework--one should enable it to be able to use
the 561 field). Save teh record.
3. Try to find the record with the general keyword search, with the words
you used. If they were specific enough, you will get no results.
4. Apply the patch, reindex with:
sudo koha-elasticsearch --rebuild -r -b kohadev
5. Confirm that now you are able to find the record with the information
you entered.
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Extension to bug 36269: 1) when cataloguing old prints, the standardized form of
the place of publication is given in the field 752 and as such should also be indexed.
2) Also, normal UNIMARC fields for publication place should be indexed (210a, 214a).
Test plan
=========
Scenario A (MARC 21, field 752)
-------------------------------
0. Have an installation with Elasticsearch and MARC 21 configuration.
1. Activate subfields 752 $a, $d in the default framework (Visibility: Editor).
2. Edit an existing record with this framework, putting some rare words in the
752 $a and $d subfields.
3. Try to make a search with tis words (general keyword or by publication place,
i.e. pl:).
4. You hsold get no results.
5. Apply the patch, reindex with:
sudo koha-elasticsearch --rebuild -r -b kohadev
6. Repeat p. 3. You should get your edited record.
Scenario B (UNIMARC)
--------------------
0. Have an installation with Elasticsearch and UNIMARC configuration.
1. Try to search for a publication place, either with pl: directly in the
search window, or in Advanced search, with Publisher location.
With ktd UNIMARC test date you can search for 'Ste Geneviève Cedex'.
2. You should get no results.
3. Apply the patch, reindex with:
sudo koha-elasticsearch --rebuild -r -b kohadev
4. Repeat p. 1. You should get some results (with ktd test data set and
Ste Geneviève Cedex - record #1).
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a new index for authorities, Other-control-number, and maps it to 035$a.
This will help when trying to match authority records when importing external records.
Test 1:
0. Make sure Elasticsearch is set as the search engine
1. Apply patch and restart
2. Import the attached record
2.1. Go to Cataloging > Stage records for import
2.2. Choose the file
2.3. Click Upload file
2.4. Choose Record type: Authority
2.5. Click Stage for import
(wait until the job is finished...)
2.6. Click View batch
2.7. Click Import this batch into the catalog
(wait until the job is finished...)
2.8. Click Manage imported batch
2.9. Click View next to the record
2.10. Note the auth id number
3. Examine the ES entry for the record (replace INDEX_NAME with the index name (found in koha-conf.xml and XX with the auth_id)
curl -XGET 'http://localhost:9200/INDEX_NAME_authorities/data/XX?_source_includes=other-control-number&pretty'
--> It should give you the value of 035$a
Test 2 (optional):
1. Steps 1 and 2 as above
2. Add a matching rule to match on 035$a for authority records
2.1. Go to Administration > Record matching rules
2.2. Click New record matching rule
2.3. Fill out the form
- Matching rule code: enter a code (for example AUTCONTROL)
- Description: enter a description (for example 035$a for authorities)
- Match threshold: 100
- Record type: Authority record
- Search index: Other-control-number
- Score: 100
- Tag: 035
- Subfields: a
2.4. Click Save
3. Import the same record again, checking for matches using the new rule
3.1. Go to Cataloging > Stage records for import
3.2. Choose the file
3.3. Click Upload file
3.4. Choose Record type: Authority
3.5. Choose Record matching rule: rule created above
2.6. Click Stage for import
(wait until the job is finished...)
--> It should say that 1 record was found using the rule
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the relator code gdv (Game developer) in the list of
MARC21 relator terms in Koha.
To test:
1. Apply patch and reset_all
2. Go to Administration > Authorized values > RELTERMS
3. Search for gdv
--> The new relator code should be there with its corresponding term
"Game developer"
Note: this is added in the installer files. It will not affect existing
installations. For existing installations, add the new relator code in
Administration > Authorized values > RELTERMS.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the default MARC21 framework to reflect the changes
brought by Update 37 (December 2023).
To test:
1. Apply patch and reset_all
2. Go to Administration > MARC bibliographic framework
3. Click Actions next to the default framework and choose MARC structure
4. Check for the changes detailed in the update
https://www.loc.gov/marc/bibliographic/bdapndxg.html
- Two subfields of 022 should be marked as obsolete
- l ISSN-L [OBSOLETE]
- m Canceled ISSN-L [OBSOLETE]
- There should be a new field 023, named CLUSTER ISSN
- This field should be repeatable
- Subfields:
- 0 Authority record control number or standard number (NR)
- 1 Real World Object URI (R)
- 2 Source (NR)
- 6 Linkage (NR)
- 8 Field link and sequence number (R)
- a Cluster ISSN (NR)
- y Incorrect Cluster ISSN (R)
- z Canceled Cluster ISSN (R)
- There should be one new subfield in field 532
- 3 Materials specified (NR)
5. Optional: run the framework test in Administration > MARC
bibliographic framework test
--> All should be OK
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds comments to the template to highlight the markup
structure.
This patch should have no effect on the page's appearance or
functionality.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch reindents the tags review template so that it has consistent
indentation, with tab indentation coverted to space.
The patch also adds "FILTER collapse" around the <style> block in the
head of the page.
To test, apply the patch and go to Tools -> Tags.
- The page should look unchanged.
- Test that no functionality has been affected:
- Tag searches
- Tag status changes
- Check lists
- If you view the diff while ignoring whitespace the only changes should
be places where line breaks were introduced
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the changed code to set the logged in librarian as
the person who resolved the return claim at checkin/checkout action.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch further unit tests highlighting possible issues
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds unit tests that test the functionality more specifically
and adds a few notes/fixme for things we need to consider here
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We're actioning the change of claim status outside of any block that
checks the $item exists. As such we'll want to add that check in here.
I did consider that this should live inside AddIssue, but on reflection
the librarian may want to not proceed with the issue given other return
values from the CanBookBeIssued call, but you still want the
AutoClaimReturn to fire regardless as you've now found the item.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The new logic in AddReturn was flawed, we were missing return messages
due to moving the if statement too high and catching more code than
intended.
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Add unit tests for new logic introduced to C4::Circulation::AddReturn
Signed-off-by: Andrew Fuerste Henry <andrewfh@dubcolib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Configure Claims returned
1. Go to Administration > Authorized Values > LOST
2. Add a new authorized value with value:6 and description:Claims returned
3. Go to Administration > System Preferences
4. Set ClaimReturnedLostValue to 6 and save
2. Check out an item to a patron.
1. Mark the item as claim returned
2. Check the item in.
3. A message stating that the item has been claimed as returned pops up with
an option to resolve.
4. Resolve the claim.
3. Check out the item to the patron again.
1. Mark the item as claim returned.
2. Check out the item to a new patron. Select “Yes, check out”
3. Go back to the previous patron. Notice that their claim was not resolved.
4. Apply the patch.
1. Updatedatabase
2. restart_all
3. Go to the system preferences and set the system preference
‘AutoClaimReturnStatusOnCheckin’ to ‘Returned by patron’
4. Set ‘AutoClaimReturnStatusOnCheckout’ to ‘Found in library’
5. Redo step 2
1. When checking the claim returned item in you will now see a message that
says “The previously claimed returned item has been found, automatically
resolving the associated claim.”
2. View the previous patron. Their claim has automatically been resolved
with a status of ‘Returned by patron’
6. Redo step 3
1. Upon checking the item out to another patron you will see a message that
says “The previously claimed returned item has been found, automatically
resolving the associated claim.”
2. View the previous patron. Their claim has automatically been resolved
with a status of ‘Found in library’.
7. Sign off and have a wonderful day!
Sponsored-by: Altadena Library District
Signed-off-by: Andrew Fuerste Henry <andrewfh@dubcolib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When we renew a notice with a specific date and we have to override the limit, the new date due is not the date that we picked
To reproduce
1- Log in to the staff interface
1-1. Make sure you have a ciculation rule that allows you to renew
1-2. set the AllowRenewalLimitOverride system preference to Allow and SpecifyDueDate to Allow
2. Check out the item to a Borrower
5. Access the borrower's account and renew it until the limit is reached and note the due date.
6. Go to Circulation, click Renew
7. Enter the item barcode and choose a due date further than the due date from step 5 and submit
8. Click on Override limit and renew button
---> Note that the new date due is not the date that we picked in step 7
9. Apply the patch
10. Repeat step 6, 7 snd 8
---> Note that the new date due is the date that we picked
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This adds a --status switch to the koha-plack command.
To test on ktd:
- Copy the script to /usr/sbin, so you run the modified script,
and not the one installed by Koha:
$ sudo cp debian/scripts/koha-plack /usr/sbin/
- Stop and start Plack for kohadev like so:
$ sudo koha-plack --stop kohadev
$ sudo koha-plack --start kohadev
And make sure this reports the correct status, both when Plack
is running and when it is not running:
$ sudo koha-plack --status kohadev
- Make sure --status is mentioned here:
$ sudo koha-plack --help
- See https://wiki.koha-community.org/wiki/Testing_man_pages for
details on how to check the manual page for the command
Signed-off-by: Tadeusz Sośnierz <tadeusz@sosnierz.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the unit tests for the new system preferences that will
automatically change an items lost status to an authorised value defined
in these preferences on payment or write off of outstanding balance.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch implements two new system preferences, "UpdateItemLostStatusWhenWriteOff" and "UpdateItemLostStatusWhenPaid" that allow you to specify the status to change an item to when the outstanding balance of a lost item is paid or written off. These preferences are tied to the LOST authorised values set.
Test Plan:
- Set one of the system preference to any of the available values
- Set an item as lost
- Make a manual invoice for your desired user and assign it to the barcode of the above item
- Save and Pay
- Select Pay/Write Off depending on the system preference you selected above
- Pay
- Note that the status of the item has changed to the status you set with the system preference
- Repeat for all values of both system preferences
- Check that when the system preference is left blank and no option is chosen, the lost status does not update.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
