This patch makes the different ->recalls accessors implemented on this
bug be more standard. This means:
- They don't do special things like default sorting or stripping out
special parameters. That's all left to the caller and the methods are
clean: they just return the related objects
- Useful filtering methods for Koha::Recalls resultsets are added. The
only used one (in the end) was ->filter_by_current. It seems like a
better approach, because it gives devs more control on how they want
to chain things, and there's a single place in which to maintain the
criteria of what is 'current' or 'finished'. This clearly makes the
'old' column obsolete IMHO, at least in the use cases I found. This is
covered by tests as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
- fixes the displays of opac-recalls.pl and opac-recall.pl
- fix the error on Recalls to pull page
- fix JS error preventing Recalled link from showing in checkouts table
- fix cancelling of recall when checking out item
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
See recalls on Intranet
- old recalls (all inactive recalls)
- recalls queue (all active recalls) - cancel, expire, revert waiting status, multiple cancel, mark overdue
- recalls to pull (available but not yet waiting) - cancel
- recalls awaiting pickup (awaiting pickup, awaiting pickup more than RecallMaxPickUpDelay days) - expire, revert waiting status
- overdue recalls (overdue to be returned) - cancel, multiple cancel
- biblio recalls tab (all active recalls relevant to this bib) - cancel, expire, revert waiting status, mark overdue
- patron recalls tab (all active recalls relevant to this patron) - cancel, expire, revert waiting status, mark overdue
- patron recalls history tab (all recalls relevant to this patron) - cancel, expire, revert waiting status, mark overdue
- log viewer
and the general circulation of recalls
== TEST PLAN FOR RECALLS ==
ADMINISTRATION
1. Apply all patches
2. Run database updates, update schema files and confirm everything applies cleanly
3. Run tests and confirm everything passes:
t/db_dependent/Koha/Recall.t
t/db_dependent/Koha/Recalls.t
t/db_dependent/Stats.t
t/db_dependent/Circulation/CalcFine.t
t/db_dependent/Koha/Item.t
t/db_dependent/Koha/Biblio.t
t/db_dependent/Koha/Patron.t
t/db_dependent/XSLT.t
t/db_dependent/Search.t
t/db_dependent/Holds.t
t/db_dependent/Circulation/transferbook.t
t/db_dependent/Circulation.t
4. Go to Administration -> system preferences. Find the UseRecalls system preference. It should be DISABLED. Confirm RecallsMaxPickUpDelay is set to 7 by default.
5. Go to Administration -> circulation rules. Confirm there are no recalls circulation rules showing.
6. Test a few circulation flows: checking out, placing a reserve, checking in, fulfilling a reserve, etc. Confirm everything works as normal.
7. Go to Administration -> system preferences. Enable the UseRecalls system preference.
8. Go to Administration -> circulation rules. Set the following rules:
Recalls allowed (count) = 0
Recalls per record (count) = 0
On shelf recalls allowed ( If any unavailable / If all unavailable ) = If any unavailable
Recall due date interval (days) = 3
Recall overdue fine amount = (something different to your normal fine amount)
Recall pickup period (days) = 1
Throughout your testing, try with different combinations of these rules and itemtype / branchcode / categorycode. Also try with null values. Keep the circulation rules open in another tab so you can refer to and update these easily. You should also have at least one other tab open for the staff client, and a third tab open for the OPAC, for ease of testing.
9. Go to your account -> More -> Set permissions. Confirm the recalls permission is checked.
10. Set up a test user with OPAC login details (Borrower A). This could also be your own user, as long as you have OPAC login access.
11. Set up a test record (Biblio A) with at least two items (Item A and Item B) of the same item type (or an item type with the same recall circ rules).
PLACING A RECALL
12. Log in to the OPAC as Borrower A. Do a catalogue search with a term that will return multiple results, including Biblio A.
13. Click on Biblio A.
14. Notice there is a 'Place recall' button on the sidebar menu. Click this button. There will be a message saying that there are no items to recall - this is because all items are available.
15. Check out Item A to another borrower (Borrower B).
16. Refresh the 'Place recall' page. You will still NOT be able to place a recall - this is because Recalls allowed = 0 and Recalls per record = 0.
17. Edit the circulation rules to have the following values:
Recalls allowed (count) = 1
Recalls per record (count) = 1
18. Refresh the 'Place recall' page. You will now see the form to place a recall.
BIBLIO-LEVEL RECALL, NO TRANSFER
19. Place a biblio-level recall.
Pickup location: Branch A, the set branch when you are logged into the staff client
Recall not needed after (expiration date): whatever you want
Select 'recall next available item'
Click confirm
20. Confirm the recall is placed successfully. Confirm that the new due date displayed is correctly calculated to be today's date, plus 3 days (taken from the 'recall due date interval' circ rule)
21. In the staff client, look at Borrower B's account, and go to their Notices tab. Confirm they have received a 'Notification to return recalled item' notice.
22. Look at Borrower B's checkouts table. Notice the due date for their checkout has been adjusted, and there is now a note to say that the item was recalled and the due date adjusted.
23. Log in to the OPAC as Borrower B and go to your summary tab. Notice there is a note under their checkout to say the item had been recalled.
24. Log out of the OPAC and log back in as Borrower A.
25. Go to your summary tab. Confirm there is a Recalls tab with a count of 1.
26. Cancel the recall using the button. Confirm it cancels and the Recalls tab disappears.
27. Do a catalogue search with a term that will return multiple results, including Biblio A.
28. When the results load, notice there is a 'Place recall' button next to the 'Place hold' button. Click this 'Place recall' button.
29. Notice you are redirected straight to the form to place a recall.
30. Place a biblio-level recall again, following the steps in Step 19.
31. Go to your recalls history tab. Notice your first cancelled recall shows here.
32. Cancel the recall you just created, using the button. Confirm it cancels and you are redirected to your summary tab.
33. In the staff client, enable the UseCourseReserves system preference.
34. Go to the main menu, click Course Reserves.
35. Add a new course. (You may also have to define an authorised value for DEPARTMENT.)
36. Add Item A as a reserve to this course.
37. View Course Reserves in the OPAC. Click the course you just created.
38. Notice the reserve has a Recall button underneath it's 'Checked out' status. Click this button.
39. Place a biblio-level recall again, following the steps in Step 19.
40. Click the 'Place recall' link in the breadcrumbs.
41. Notice there is a message saying that you have reached the max number of recalls on this record. This is because Recalls allowed = 1 and Recalls per record = 1.
42. Edit the circulation rules to have the following values:
Recalls allowed (count) = 10
Recalls per record (count) = 5
43. Refresh the 'Place recall' page. You will now see the form to place a recall.
44. Create another test record (Biblio B) with at least one item (Item C).
45. Find this record on the OPAC and place a biblio-level recall again, following the steps in Step 19.
46. In the staff client, go to Circulation -> Old recalls. You should be able to see your two cancelled recalls.
47. Go to Circulation -> Recalls queue. Your current recalls should show here.
48. Use the 'Select all' checkbox to select all recalls.
49. Cancel the recalls using the 'Cancel selected recalls' button.
50. Go to the OPAC and place a biblio-level recall on Biblio A again, following the steps in Step 19.
51. In the staff client, check in Item A, which should still be checked out to Borrower B.
52. A box should pop-up asking you to confirm Borrower A's recall. Click ignore.
53. Click the link to go view Biblio A's details in the catalogue.
54. Click the recalls tab. Notice Borrower A's recall is displayed, and shows it is still Requested (has not been confirmed waiting).
55. Check in Item A again. This time, confirm the recall as waiting using the "Confirm recall" button.
56. Go to Borrower A's Notices tab. Confirm there is a notice "Recalled item awaiting pickup".
57. Go to Borrower A's checkouts. Notice there is a recalls tab. Confirm the recall is showing as "Ready for pickup".
58. Click the 'Actions' dropdown. Click the "Revert waiting" button. The page should show a message that the waiting status has been reverted, without reloading.
59. This time, check in Item B. The recall confirmation box should show again, because this a biblio-level recall that any recallable item under Biblio A can fill. Click the "Print slip and confirm" button.
60. Check the slip that is generated. Confirm it contains Borrower A's correct details, and the details of the recall are correct.
61. Go to Circulation -> Recalls awaiting pickup. Confirm the recall is now waiting and shows in this list.
(You could also try this with Item B having a different item type to Item A, and circ rules not allowing Item B's item type to have recalls. When checking in Item A, it should not trigger the recall box).
62. Go to Borrower A's checkouts. Check out Item B.
63. Confirm the checkout is successful and the recall is removed from the Recalls tab.
64. Go to Circulation -> Old recalls. The fulfilled recall should show.
65. Check in Item B.
BIBLIO-LEVEL RECALL, TRANSFER REQUIRED
66. Check out Item A to Borrower B.
67. Log in to the OPAC as Borrower A.
68. Find Biblio A and place a biblio-level recall.
Pickup location: Branch B, a different branch from your logged in branch. This recall will require a transfer.
Recall not needed after (expiration date): whatever you want
Select 'recall next available item'
Click confirm
69. In the staff client, check in Item A at Branch A. Notice the box that pops up shows that a transfer is required.
70. Click "confirm recall and transfer" and confirm the transfer.
71. Go to your account and click the Recalls tab.
72. Confirm the recall status now shows the item is in transit to Branch B.
73. In the drop-down top-right of your window, select 'Set library'.
74. Set your library to Branch B.
75. Go to Circulation -> Transfers to receive. Notice that the recall is showing here.
76. Click 'Cancel transfer'.
77. Go to Circulation -> Recalls queue
78. Confirm the recall status has been reverted to Requested.
79. Set your library back to Branch A.
80. Check in Item A and trigger the transfer.
81. Set your library back to Branch B.
82. Check in Item A at Branch B.
83. When the 'Recall found' box pops up, click Ignore.
84. Go to Circulation -> Recalls to pull. The recall should show here, with a button to "Cancel recall and return to: Branch A"
85. Click the button to cancel the recall.
86. Repeat Steps 66-70.
87. Check in Item A at Branch B. Confirm the recall as waiting.
88. Check out Item A to Borrower A to fulfill the recall.
89. Set your library back to Branch A and check in Item A.
ITEM-LEVEL RECALL, NO TRANSFER
90. Go to Administration -> circulation rules. Set the following rules:
On shelf recalls allowed ( If any unavailable / If all unavailable ) = If all unavailable
91. Check out Item A to Borrower B.
92. Log in to the OPAC as Borrower A and go to Biblio A.
93. Click the 'Place recall' button. Confirm there is a message that there are no items to recall. This is because On shelf recalls allowed = If all unavailable, and there is still one item (Item B) available.
94. In the staff client, edit Item B to have a withdrawn, item lost or not for loan status.
95. Refresh the 'Place recall' page. Confirm you can now see the form to place a recall.
96. Place an item-level recall.
Pickup location: Branch A.
Recall not needed after (expiration date): whatever you want
Select 'recall a specific item'
Item B will not be selectable, and Item A should be selected by default.
Click confirm
97. In the staff client, edit Item B and remove the lost or missing status.
98. Check in Item B. Confirm the recall box does not pop up, because it cannot fill the item-level recall.
99. Check in Item A. Confirm the recall as waiting.
100. Go to Circulation -> Recalls awaiting pickup
101. Expire the recall. Confirm it expires as expected.
ITEM-LEVEL RECALL, TRANSFER REQUIRED
102. Repeat steps 91 to 95.
103. Place an item-level recall.
Pickup location: Branch B, we will require a transfer.
Recall not needed after (expiration date): whatever you want
Select 'recall a specific item'
Item B will not be selectable, and Item A should be selected by default.
Click confirm
104. In the staff client, check in Item A. Confirm the recall and trigger the transfer.
105. Set your library to Branch B and check in Item A.
106. Confirm the recall as waiting.
107. Check out Item A to Borrower A and fulfill the recall.
108. Set your library back to Branch A and check in Item A.
CRONJOBS: EXPIRING RECALL
109. Check out Item A to Borrower B.
110. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
111. In your terminal, enter mysql and edit the expiration date of your recall to be before today
UPDATE recalls SET expirationdate = NOW()-2 WHERE recall_id = X;
112. Run the expiry cronjob from within your shell
perl misc/cronjobs/recalls/expire_recalls.pl
113. Go to Borrower A's account and go to the Recalls history tab
114. Confirm the recall has been expired because the current date surpassed the specified expiration date
115. Check out Item A to Borrower B.
116. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
117. In the staff client, check in Item A and confirm the recall as waiting.
118. In your terminal, enter mysql and edit the waiting date of your recall to be before today
UPDATE recalls SET waitingdate = NOW() - interval 5 day WHERE recall_id = X;
119. Run the expiry cronjob from within your shell
perl misc/cronjobs/recalls/expire_recalls.pl
120. Go to Borrower A's account and go to the Recalls history tab
121. Confirm the recall has been expired because the recall had been waiting for more days than the Recall pickup period
122. Go to Administration -> circulation rules. Set the following rules:
Recall pickup period (days) = 0
123. Set the RecallsMaxPickUpDelay system preference = 1.
124. Check out Item A to Borrower B.
125. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
126. In the staff client, check in Item A and confirm the recall as waiting.
127. In your terminal, enter mysql and edit the waiting date of your recall to be before today
UPDATE recalls SET waitingdate = NOW()-2 WHERE recall_id = X;
128. Run the expiry cronjob from within your shell
perl misc/cronjobs/recalls/expire_recalls.pl
129. Go to Borrower A's account and go to the Recalls history tab
130. Confirm the recall has been expired because the recall had been waiting for more days than the RecallsMaxPickUpDelay syspref
CRONJOBS: OVERDUE RECALL
131. Check out Item A to Borrower B
132. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
133. In your terminal, enter mysql and edit the due date of the checkout to Borrower B to be before today
UPDATE issues SET date_due = NOW()-2 WHERE issue_id = X;
134. Run the overdue cronjob from within your shell
perl misc/cronjobs/recall/overdue_recalls.pl
135. Go to Circulation -> Overdue recalls
136. Confirm your recall is showing here now as the recall has been marked Overdue
CIRCULATION
137. Check in Item A.
138. When the recall box pops up, click Ignore.
139. Check out Item A to Borrower B. You should see a yellow confirmation box, saying that another borrower has recalled the item you are trying to check out.
140. Click "No don't check out" and confirm the item isn't checked out and the recall remains.
141. Repeat Step 139.
142. Click "Yes check out" and confirm the item is checked out and the recall remains.
143. When Borrower B's checkout table loads, confirm that you cannot renew or check in the item from the Checkouts table because there is a 'Recalled' link which takes you to the recalls tab for that biblio.
144. Repeat Steps 137-139.
145. Select "Cancel recall" and click "Yes check out" and confirm the item is checked out and the recall has been cancelled.
146. Log in to the OPAC as Borrower A. Place a recall (any level) on Biblio A.
147. Check in Item A. Confirm the recall as waiting.
148. Check out Item A to Borrower B. You should see a yellow confirmation box, saying that that another borrower has recalled the item that you are trying to check out.
149. Select "Revert waiting status" and click "Yes check out" and confirm the item is checked out and the recall status has reverted to requested.
OTHER
150. In your terminal, enter mysql and edit the due date of the checkout to Borrower B to be before today
UPDATE issues SET date_due = NOW()-2 WHERE issue_id = X;
151. Go to Borrower A's recalls and click the Actions dropdown.
152. Click "Mark as overdue" and confirm the recall is marked as overdue manually.
153. Go to Tools -> Log Viewer. Check only the Recalls module, and leave all other parameters, and click Submit.
154. Confirm all of the recalls actions that have been made are correctly logged.
Note: recalls messaging preferences are introduced in Bug 23781.
The recall feature is fully documented at: https://wiki.koha-community.org/wiki/Catalyst_IT_Recalls
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The current handling of onsite checkouts with OnSiteCheckoutsForce
syspref enabled is confusing and hard to understand. It's also fragile
with a high risk future changes could result in subtle bugs.
Also fix an inconsistency in which errors (DEBT_GUARANTORS) are considered blocking for
forced onsite checkouts.
To test:
1) Enable OnSiteCheckouts, disable OnSiteCheckoutsForce
2) Edit a biblio item and for example set Not for loan to a value
restricting loans
3) Try to check out the item for some patron
4) A message that item is not for loan should be displayed
5) Select "On-site checkout" and try again
6) The same message should be displayed
7) Try to checkout with some invalid barcode
8) A message that barcode was not found should be displayed
9) Now enable OnSiteCheckoutsForce
10) Try to checkout the item for some patron
11) A message that item is not for loan should be displayed
12) Select "On-site checkout" and try again
13) Checkout should now succeed, no messages should be displayed
14) Try to checkout with some invalid barcode
15) A message that barcode was not found should be displayed
16) All of the above steps should produce the same result with and without this patch
Additional:
Before patch:
a) Set NoIssuesChargeGuarantorsWithGuarantees to 1
b) add a guarantee with another guarantor
c) charge a 1.01 fine to other guarantor
d) checkout is blocked due to fines
Apply patch
e) checkout is allowed when onsite checkouts forced
Sponsored-by: Gothenburg University Library
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If I access circulation.pl directly, with no patron cardnumber or borrowernumber submitted, I get an error:
Can't call method "messages" on an undefined value at /kohadevbox/koha/circ/circulation.pl line 525
This is caused by Bug 29230 which calls $patron outside a
"if ($aptron)".
Test plan :
1) In staff interface, click in 'check out' search box
2) Hit enter (without a search text)
=> Without patch you get an error
=> With patch you see a blank page /cgi-bin/koha/circ/circulation.pl
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Add methods to return the messages attached to a patron.
It will add the capability to access them from notice templates.
Test plan:
Define some messages for a given patron
Go to the circulation page of the patron and confirm that they are still
displayed
Test the notice templates:
Add to HOLD_SLIP the following content
"""
[% SET messages = borrower.messages %]
[% IF messages.count %]
Messages:
<ul>
[% FOR m IN messages.search( message_type => 'L' ) %]
<li>[% m.message %]</li>
[% END %]
</ul>
[% END %]
"""
To display all the messages from staff ('L')
Adapt following your needs.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Stina Hallin <stina.hallin@ub.lu.se>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On bug 29844 we decided to remove wantarray from Koha::Objects->search.
Reviewing the difference occurrences I found some unnecessary uses of ->as_list,
where iterators should be used instead.
This patch only removes the obvious places, not the tricky ones.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 26352 changed the line in circ/circulation.pl that searches for a
patron card number in the barcode field from using the $barcode variable
to the $findborrower variable. This breaks AutoSwitchPatron.
Test plan:
1. make sure AutoSwitchPatron system preference is on.
2. get two patron card numbers.
3. enter the first card number to check out to the patron.
4. enter the second card number in the item barcode field.
5. observe that the barcode is not found.
6. apply patch
7. enter the second card number in the item barcode field again.
8. observe that the second patron is loaded to check out to.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To test:
1) go to the main page of Koha and search in the "Check out" search window type "näyttö".
2) see that umlauts got replaced with replacement characters.
3) apply the patch.
4) repeat 1-2, ensure that umlauts displayed correctly and are not getting replaced with replacement characters.
JK: remove period from commit title
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is based on Julian's idea on bug 28026 where we could get rid of call_recursive by passing refs as arguments to call.
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Koha/Plugins/Plugins.t
3) prove t/db_dependent/Koha/Plugins/Barcode_transform_hooks.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The 'Checkout' search hijacks some of the DataTables searching code used for 'Search patrons'
Rather than try to implement the search again on another page, we can simply send the user
to the patron search if the cardnumber is not found
Additionally, this patch adds a 'Check out' button to the patron search results to allow
going to checkotus directly
To test:
1 - Apply patch
2 - Perform a 'Checkout' search from the header
3 - Note that:
For a cardnumber, you are redirected directly to checkouts page for the borrower
For a search with one result, you are redirected directly to the checkout page for the borrower
For a search with many results, you are redirected to the patron search results
and there is a 'Checkout' button under the cardnumber
4 - Confirm circulation page works as expected (i.e. checkout to a patron)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: George Williams <george@nekls.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some of our partners have unusual barcode requirements that have
required us to transform scanned barcodes using javascript. This is not
the most reliable method. It would make more sense to have Koha
transform the barcodes on the backend using a plugin. We should add
hooks to transform and generate new item and patron barcodes.
Test Plan:
1) Apply this patch
2) Download and install the Barcode Transformer plugin
https://github.com/bywatersolutions/koha-plugin-barcode-transformer/releases/download/v1.0.1/koha-plugin-barcode-transformer-v1.0.1.kpz
3) Go to the plugin configuration page, set the configuration to the example configuration from the same page
4) In the patron search and anywhere else you can scan a patron
cardnumber, type in some cardnumbers but prefix them with A and postfix
them with A or B, e.g. A12345A, A12345B
5) Note the letters are removed by Koha!
6) Try a cardnumber like X123456Y
7) Note Koha converts it to Z13456Z
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some of our partners have unusual barcode requirements that have
required us to transform scanned barcodes using javascript. This is not
the most reliable method. It would make more sense to have Koha
transform the barcodes on the backend using a plugin. We should add
hooks to transform and generate new item and patron barcodes.
Test Plan:
1) Apply this patch
2) Download and install the Barcode Transformer plugin
https://github.com/bywatersolutions/koha-plugin-barcode-transformer/releases/
3) Go to the plugin configuration page, set the configuration to the example configuration from the same page
4) In the item barcode field on the checkin and checkout pages,
and anywhere else you can scan an item barcode, type in some
valid barcodes, but prefix them with X and postfix them with
Y, e.g. X123456Y
5) Note the letters are removed by Koha!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: (QA follow-up) Fix QA script issue
* Fixes issue with barcode generate stub so perlcritic is happy
* Removes extra semicolon from return call in configure method
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: Add unit tests
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: (QA follow-up) Remove unused method barcode_transform
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: (QA follow-up) Rename barcode_transform to item_barcode_transform
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: (QA follow-up) Barcodes inputted into Koha should always pass though barcodedecode
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: (QA follow-up) Catch one last case of itemBarcodeInputFilter
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: (QA follow-up) Fix Checkouts.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: Use call_recursive() as a replacement for call()
The method `call()` is not sufficient for barcode transformations. It's
possible that more than one barcode transformation plugin will be
installed. The `call_recursive()` method takes the output of the first
plugin and uses it as the input for the next plugin and so on. This allowes
each plugin to see the current version of the barcode and modify it if
necessary.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 26351: Fix t/db_dependent/Koha/Plugins/Circulation_hooks.t
Bug 26351: Revert improper change to unit test, fix number of tests
Bug 26351: Remove uneeded use Koha::Plugins statements
Left over from previous changes
Bug 26351: Add missing barcodedecode import
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch creates a new include for showing circulation and
patron-related messages on both the checkout page and the patron detail
page. This allows the two pages to be consistent with each other.
The patch also makes some minor CSS adjustments, including the addition
of an SVG to replace an old GIF, arrow-bullet.gif.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- View both the checkout and patron details page for patrons in the
staff interface, confirming that the information is displayed in the
same way, including:
- Pending modifications
- Pending expiration
- Expired
- Address in doubt
- Card lost
- Restricted (indefinite and with expiration)
- Outstanding overdues
- Outstanding return claims
- Patron age incorrect for their category
- Outstanding charges
- Account credit
- Waiting holds (at logged-in library or other library)
- Circulation note (from borrowers.borrowernotes)
- Messages (added at logged-in library or other library)
EDIT: Fixed merge error.
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>
Using itemBarcodeFallbackSearch entering a barcode on checkout will do a keyword
search and provide you with a list of items matching the search term for checkout.
This allows checking out items, where there is no barcode in the item (you still need
a dummy barcode in Koha).
At the moment the table of items to choose from will only chow the title and the dummy barcode.
In order to make it more useful and easier to identify the correct item,
we should show more information here:
- callnumber (952$o)
- serial enumeration (952$h)
- copy number (952$t)
- inventory number (952$i)
(description copier from comment 0)
Test plan:
- Turn on itemBarcodeFallbackSearch
(If you have ES you need bug 27597)
- Check an item out using "street" or a search that will return several
items
- Note that you have now more info about the items
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a new type of system preference entry option: patron
category. A preference with this type will show either a <select> with
patron categories to choose from or a multiple-select menu for choosing
one or more.
This prevents possible errors from incorrect category codes being
entered manually.
To test, apply the patch and run the database update.
- Go to Administration -> System preferences.
- Test each of the updated preferences to confirm that the available
options are correct and that your selections are correctly saved.
- Single category selections, PatronSelfRegistrationDefaultCategory
and GoogleOpenIDConnectDefaultCategory. With each of these you
should see a dropdown where you can select of all the existing
patron categories.
- Multiple selections, OPACHoldsIfAvailableAtPickup and
BatchCheckouts: These preferences should have an option for
selecting one or more system preferences at once.
- Test the pages affected by the updated system preferences:
- With BatchCheckouts enabled, confirm that the batch checkout page is
correctly limited by patron category.
- Set the OPACHoldsIfAvailableAtPickup preference to "Don't allow" and
select at least one patron category in the
OPACHoldsIfAvailableAtPickupExceptions preference.
- Log in to the OPAC as a patron whose category was not selected in
the OPACHoldsIfAvailableAtPickupExceptions preference.
- Try to place a hold on an item which is available at a library.
- When confirming the hold, the libraries where the item is available
should be disabled in the "Pick up location" dropdown.
- Repeat the process as a patron whose category was selected in
OPACHoldsIfAvailableAtPickupExceptions. There should be no disabled
pickup locations.
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>
This prevents checking out to a patron an item with hold to someone
else in the In Processing state via staff interface.
Also the checkout error message via SIP is now a more clearer one: "Item is
on hold for another patron." Before it was "Item cannot be issued:
$confirmation".
Also the branch transfer and batch checkout pages are adapted to this new
confirmation message as well.
To test:
1) Create bib level hold to an item for patron A
2) Check-in that item via SIP2, now the hold state should be "In processing"
3) Apply patch
4) Try to checkout the item to patron B via staff interface and
notice we get now confirmation prompt do we really want to do it
because it is in processing.
In order to not have to setup SIP2 server, alternatively steps 1) and
2) can be done so that you check-in the item in staff interface and
make it Waiting, and then with SQL change it to "In processing":
UPDATE reserves SET found = "P" WHERE reserve_id = XXX;
UPDATE reserves SET waitingdate = NULL WHERE reserve_id = XX
UPDATE reserves SET expirationdate = NULL WHERE reserve_id = XXX;
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The patch "Bug 19116: Hold not set to waiting after transfer" added a
new meaning to 'Reserved' return value of C4::Reserves::CheckReserves
function. Let's remove double usage and have separate Transferred
return value so we can differentiate between attached and non-attached
holds. This will come useful in future refactorings.
This patch does no changes to the logic except in the
/cgi-bin/koha/circ/branchtransfers.pl and circulation.pl we now give
similarly to waiting state notice about hold being transferred.
To test:
1) Apply this patch
2) Create a new item level hold so that pickup library is different
than where the item is currently. Then return the item so that hold
is being attached and transferred.
3) Go to branchtransfers.pl and try to create a new transfer: it
should prompt you with message "Item is attached to a hold and
being transferred for XXX" and provide you with option to cancel
the hold or to ignore the transfer.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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 not only block the circulation of a guarantor based on fines owed by guarantees, but would also like to block circulation for all guarantees as well. Basically, if a family as a whole reaches a certain threshold of fines, the entire family will be blocked from checking out items.
Test Plan:
1) Apply this patch
2) Set NoIssuesChargeGuarantorsWithGuarantees to $14
3) Create a family of four ( 2 guarantors, 2 guarantees ) where the parents guarantee both children
4) Give 3 of the 4 a $5 fine
5) None of them should be able to check out items
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch capitalizes the 'ADDITIONAL_MATERIALS' key in the
needsconfirm hash return value for CanBookBeIssued to restore
consistency with previous code and ensure SIP Checkout works as
expected.
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>
It defaults to 0 in get_template_and_user
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>
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>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
There is some quite old and unused code in Koha related
to printer configuration and network printing. These code
hasn't been functional in a long time and should be removed.
This patch:
- Removes printcirculationslips system preference
- Removes table printers
- Removes branchprinter column from branches
Check that:
- Go to administration
- Open any age there, but change the last bit to: printers.pl
- Apply patch, run the database update
- Verify the hidden page no longer exists
- Verify that logging in and out still works correctly
- Verify that checkout and returns work correctly
- Switch to another branch using the "Set library" option
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>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
NO_LIBRARY_SET was used when the DB user was logged in. Since bug 20489
it's not longer possible. We could remove the code.
One occurrence left in C4::InstallAuth as there is no (real) logged in user yet.
Test plan:
* Install Koha to make sure NO_LIBRARY_SET is not needed during the
install process
* Login into Koha
* Make sure the your library's name is displayed correctly in the header
* Set another library
* Confirm that the library's name is updated
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No problem during install, nor changing library.
Fixed (pre-existing) tab in circ/branchtransfers.pl
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We certainly faced 3 similar bugs due to this syntax: bug 23006, bug
22941 and bug 17526.
To prevent other issues related to this syntax this patch suggests to
replace them all in one go.
Test plan:
Confirm that the 2 syntaxes are similar
Eyeball the patch and confirm that there is no typo!
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>
The auto_renew parameter is not sent to the template when the popup
triggered by itemBarcodeFallbackSearch is displayed.
Test plan:
- Turn on itemBarcodeFallbackSearch
- Open a patron account
- Check the checkboxes for automatic-renewal
- Search for a title keyword in the checkout input box
- Verify that auto-renewal flag is set
Note for QA: The auto_renew flag will be set in any cases. Should we
expect regression?
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This adds a "Claims returned" feature that extends and enhances the claims returned lost status.
To use this feature, a new LOST status to represent an item claimed as returned needs to be created.
The value of this LOST authorised value should be set in the new syspref ClaimReturnedLostValue.
Setting this system preference turns on the feature.
Once the feature is enabled, you should be able to mark checked out items as return claims from the
checkout and patron details pages, and also modify them from the new claims tab on those pages.
Returning a claimed item will notify the librarian that the item in question has a claim on it.
Setting the ClaimReturnedWarningThreshold will add an alert to make librarians aware that this
patron has many return claims on the patron's record.
Test Plan:
1) Create a "Claims Returned" lost value
2) Create some RETURN_CLAIM_RESOLUTION authorized values
3) Set ClaimReturnedLostValue
4) Set ClaimReturnedChargeFee
5) Set ClaimReturnedWarningThreshold
6) Create some checkouts
7) Claim some returns
8) Verify ClaimReturnedChargeFee works with all 3 options
9) Verify ClaimReturnedWarningThreshold shows a warning once the threshold has been exceeded
10) Edit notes on a claim
11) Resolve a claim
12) Delete a claim
Sponsored-by: North Central Regional Library System
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Just a find and replace on the changed system preference name.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
- Rename CircAutocompl system preference to PatronAutocompletion
- Take this system preference into consideration for patron search
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>
Prevent from checking again and again the onsite checkout box when
doing onsite checkouts in batches. If preceding checkout was an onsite
one, the box will be checked.
Test plan:
1. enable OnSiteCheckouts
2. make your circulation rules able to checkout onsite
3. onsite checkout a document
4. you should return to the checkout page, the box isn't checked
5. apply patch
6. updatedatabase.pl
7. redo steps 3, it should again print a checkout page with an
unchecked onsite checkout box
8. enable OnSiteCheckoutAutoCheck system preference
9. redo step 3
10. when returning to the checkout page, the onsite checkout box
should be already checked
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds the ability to set an unlimited number of guarantors
for a given patron. As before, each guarantor may be linked to another
Koha patron, and all the behavior that applies to a given guarantor
remains the same.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Find some patrons with guarantors, verify the still have their guarantor
4) Test adding and removing guarantors on a patron record, both Koha users and not
5) Verify the "Add child" button works
6) Verify NoIssuesChargeGuarantees still works
7) Verify tools/cleanborrowers.pl will not delete a guarantor
8) Verify the guarantors are displayed on moremember.pl
9) Verify the guarantor is removed by members/update-child.pl
10) Verify the guarantor is removed by misc/cronjobs/j2a.pl
11) Verify import patrons converts guarantor_id, relationship, contactfirstname,
and contactsurname into a guarantor
12) prove t/Patron.t
13) prove t/db_dependent/Circulation.t
14) prove t/db_dependent/Circulation/NoIssuesChargeGuarantees.t
15) prove t/db_dependent/Items.t
16) prove t/db_dependent/Koha/Patrons.t
17) prove t/db_dependent/Members.t
18) prove t/db_dependent/Patron/Relationships.t
Signed-off-by: Kim Peine <kmpeine@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Changed the method introduced into Koha::Patron from is_category_valid
to the more specific is_valid_age to clarify it's intent to future
developers.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a warning if a patron's age is out of limits if an assigned category.
It also adds a button allowing to change the category.
Test plan:
1) Apply patch
2) Create a patron and assign him a category having age limits set
3) Change patron's age to be older/younger than category's limits
4) At "Check out" and "Details" tabs you should see a warning with a
button allowing to change the category, eg.:
- http://prntscr.com/cz7ch3
- http://prntscr.com/cz7em4
- http://prntscr.com/cz7dj1
5) Set a valid category according to patron's age
6) Warning should disappear
7) Perform similar test again, but instead of changing the age change
the limits of a category
8) During tests verify "Change category" button everytime opens "Modify
patron" page:
http://prntscr.com/cz7g5q
9) Ensure that left-side panel is always on its expected place
10) Remove patron's date of birth and test that all categories are
allowed now
11) Run automated tests: prove t/db_dependent/Koha/Patron.t
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When using preference itemBarcodeFallbackSearch one can enter a search term instead of a barcode in checkout form.
If on-site is selected this should be transmitted to itemBarcodeFallbackSearch form.
Test plan :
1) Enable system preferences "itemBarcodeFallbackSearch" and "OnSiteCheckouts"
2) Disable system preference "ConsiderOnSiteCheckoutsAsNormalCheckouts"
3) Go to a patron circulation page
4) Check "On-site checkout" in "Checkout settings"
5) Enter a barcode in checkout form and click on "Check out"
6) You see the checkout in table with red "(On-site checkout)"
7) Check "On-site checkout" in "Checkout settings"
8) Enter the title of a record in in checkout form and click on "Check out"
9) Click on "Checkout" on a line
10) You see the checkout in table with red "(On-site checkout)"
Signed-off-by: Arthur Bousquet <arthur.bousquet@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Changes:
- Replace getting preference ExtendedPatronAttributes by Koha.Preference
in templates
- Add Koha::Patron->attributes for getting patrons extended attributes
- Use this method in circ-menu.inc
- Remove getting attributes from members perl scripts
Test plan:
0) Apply the patch
1) Add some patron attributes type - with free text, authorised value,
limited by libraries...
2) Add some values to this attributes for some patrons
3) Go through as many patron pages as you can and confirm that
attributes are shown at side panel when they shoul and are not shown
when they should not be shown
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Removed Koha/Schema/Result/BorrowerAttribute.pm
[EDIT] Added missing semicolon on L114 in Koha/Patron/Attribute.pm
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Using only TT plugin for authorised value description is a better code.
Test plan :
Part 1:
1.1) On a catalog with items.notforloan defined with authorized values category NOT_LOAN
1.2) Define in NOT_LOAN an authorized values 1 with description 'at the beach'
1.3) Define in NOT_LOAN an authorized values 2 with description empty
Part 2:
2.1) Set preference 'AllowNotForLoanOverride' to 'Don't allow'
2.2) Edit an item with notforloan=1
2.3) Checkout this item => You see 'Item not for loan (at the beach)'
2.4) Edit an item with notforloan=2
2.5) Checkout this item => You see 'Item not for loan'
Part 3:
3.1) Set preference 'AllowNotForLoanOverride' to 'Allow'
3.2) Edit an item with notforloan=1
3.3) Checkout this item => You see 'Item is normally not for loan (at the beach)'
3.4) Edit an item with notforloan=2
3.5) Checkout this item => You see 'Item is normally not for loan'
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
caused by commit 105b3e10e8
bug 18789
To recreate:
1 - Set CircAutoPrintQuickSlip to 'clear'
2 - Bring up a patron in circulation
3 - Click in checkout box and hit enter to submit empty
4 - Patron is partially loaded
5 - Apply patch
6 - Restart all the things
7 - Test again
8 - Patron is cleared correctly
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The checkout form will be removed if various conditions are
met: Restrictions, a fine above noissuescharge etc.
Bug 19933 changed the conditions, so a restriction will no longer
block checkouts, if the fines are below the set limit.
To test:
- Add a restriction
- Confirm the checkouts form is replaced by a message
- Add a fine below the noissuescharge limit
- Confirm that the form reappears
- Apply the patch
- Check that the checkout form is gone now
- Remove restriction - form should reappear
- Add to the fine, so it's above the limit
- Form should disappear
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Code and variables to deal with the update child feature are not
centralized but copied/pasted in several scripts. Which leads to issues
obsviously (bug 20805 for instance).
Moreover the strings used by the templates are also in several template
files (or .inc)
To deal with that this patch introduces the idea to create 1 .inc file
per .js file
Here we have members-menu.inc for members-menu.js
Test plan:
- Remove all your adult categories (categories.category_type='A')
- Create a patron with a child category
- Try to update to adult category
=> The entry does no longer appears! (This is a change in the behaviour)
- Create one adult category
- Update to adult category
=> There is a JS confirmation message, if you accept the patron will
be updated to the adult category
- Create (at least) another adult category
- Create another child
- Update to adult category
=> No more confirmation message but a popup to select the adult category
- Pick one
=> The patron has been updated to the adult category
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
It's safer to send what we need from C4::Auth it's needed from a whole
module.
The SELECT COUNT(*) query will only be done when needed (so not made
from scripts outside of circ)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
