Fee limit should only be required if restriction is
meant to be lifted after payment. This patch makes
"Fee limit" input field required based on value of
"Lift after payment" select field.
To test:
1. Create a new restriction.
2. "Lift after payment" should be set as "No".
3. Change value as "Yes".
=> "Fee limit" should now have "Required" text
after input field.
4. Try to save restriction.
=> Text "This field is required" should be
displayed after "Fee limit".
5. Change "Lift after payment" back to "No".
=> Both texts should now be lifted.
Also test with existing restriction and make sure
restrictions are still saved without problems.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch moves the del_restrictions_after_payment from before the
actual credit application call inside Koha::Account::pay to after the
application of credits to debits in Koha::Account::Line::apply.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We remove the GetDebarments routine in 31095.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some libraries debar Patrons at the end of the year for having unpaid fines,
like in Bug 15157. Currently librarians have to manually remove this type of
debarments after Patron has paid his/her fines.
This patch adds ability to create restrictions which are lifted after
patron pays ceratain amount of fines.
To test:
1. Apply this patch.
2. Restart your services if needed.
3. Navigate to page restrictions.pl.
=> Note that table has two new colums in it, "Lift after payment?" and "Fee limit".
4. Add new restriction which has "Lift after payment?" set
as Yes and fee limit as 5.
5. Create fees for a patron so they exceed fee limit e.g. 10
6. Add restriction made in step 2. for the patron
7. Pay patrons fees partially so that they go under fee limit
=> Note that patrons restriction should now be lifted.
Also prove t/db_dependent/Patron/Borrower_Debarments.t.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds two new columns, lift_after_payment and fee_limit,
to table restriction_types. These colums are used to control
lifting patrons restrictions after paying their fees.
To test:
1. Apply this patch.
2. Update your database via updatedatabase.pl.
=> Confirm your table restriction_types has two new columns.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
if OPACHoldsIfAvailableAtPickup is set to "Don't allow" (i.e. if patrons cannot place holds on items that are available at their library), patrons cannot place holds on items that are on order (or any negative not for loan value) for pickup at their library.
Technically, those items are not "available", so they shouldn't be affected by this system preference.
To replicate:
Prerequisites :
- Have at least two libraries (I used the sample libraries)
- Have a patron in one of the libraries (I used Henry Acevedo), make sure you know the user id and password for that patron
- Make sure the circulation rules allow holds for the patron category
1. Set OPACHoldsIfAvailableAtPickup to "Don't allow"
1.1. Go to Administration > Global system preference
1.2. Search for OPACHoldsIfAvailableAtPickup
1.3. Change the value to "Don't allow"
1.4. Click "Save all Circulation preferences"
2. Make an item "On order" at the patron's library (Henry Acevedo is at Midway)
2.1. If needed, create a bibliographic record and item
2.2. Edit the item to assign the "On order" not for loan status
2.3. Change the home and holding library to the patron's library (Midway)
2.4. Click "Save changes"
3. Try to place a hold on the item through the OPAC
3.1. In the OPAC, log in as the patron
3.2. Search for the item
3.3. Click "Place hold"
--> Notice the patron's library is greyed out in the pickup location drop-down menu"
4. Apply the patch
5. Repeat step 3
--> Notice you can select the patron's library in the pickup location drop-down menu and place a hold with it
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When one tries to create an account with patron guarantor and
error occurs (already used username, wrong age etc.), guarantor
information is lost. This patch always saves added patron
guarantor information to the template param new_guarantors.
To test:
1. Create a new account but cause an error that will keep the
account from saving (enter the wrong age for a category or
give the patron a username that's already being used).
2. Search for and select a guarantor.
3. Try to save the account and wait for the "The following
fields are wrong. Please fix them." message.
=> Note that the guarantor information is gone and you need
to search for and select the guarantor again.
4. Apply this patch.
5. Repeat steps 1.-3.
=> Note that guarantor information hasn't been lost.
This patch also removes code block from duplicate patron
check because we now save param new_guarantors even if
error doesn't occur.
To test:
1. Create a new account but cause a duplicate patron error.
2. Search for and select a guarantor.
3. Try to save the account.
=> Guarantor information should persist.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch add 'patron home library' option to the OverdueNoticeFrom preference. When it's selected notification messages for overdues will be bundled and sent from the borrowing user's home library
To Test
1. Create 3 libraries B1, B2 and B3
1.1. Go to Koha administration, click on Libraries
1.2. Click New library
1.3. Fill the Library Code (ex. B1), Name(ex. B1) and email(ex. b1@test.com) fields.
2. Create a user belonging to B1
2.1. Go to patron module, click on New patron and patron
2.2. Fill the Surname,Card number,Primary email,Card number field and select B1 as Library.
3. Create 2 notices : the first belongs to B2 and the second belong to B3
3.1. Go to Cataloging module and click on new
3.2. field the required field (000 subfield 0, 003 subfield 0, 005 subfield 0, 008 subfield 0, 040 subfield c,245 subfield a, and 942 subfield c )
3.3. Click on save
3.4. In the item form, Select Home library = B2 and Current library = B2 and type a Barcode.
3.5. Repeat 3.1 3.2 3.3 3.4 to create a second notice belong to B3
4. Have (or create) a default notice for all branches in Notices and Slips Module
5. Make sure you connected to branch B2 or Switch to branch B2
6. checkout item I2 (belonging to B2) to the user created in step 2 (specifying as due date the day before (1 day overdue))
7. switch to branch B3
8. checkout item I3 (belonging to B3) to the user created in step 2 (specifying as due date the day before (1 day overdue))
9. make sure you have defined 'Overdue notice/status triggers' for that patron category, ie with Delay=1 so that 'Overdue Notice' is selected and 'Email' is checked.
Note: we have a user belong to B1, two item: I2 belong to B2, I3 belong to B3 and the user has borrowed I2 from B2 and I3 from B3.
10. Test
10.1. Search for OverdueNoticeFrom in System preferences and select item home library
10.2. from cli run 'perl ./misc/cronjobs/overdue_notices.pl'
=> Two new entries will be generated in message_queue DB table, coming from different branches that have the SAME list of overdue items.
=> The sender address is the item home library address for each entry.
11. Apply the patch
12. Search for OverdueNoticeFrom in System preferences
=> There is now 'patron home library' in the options list
13. Select patron home library
14. from cli run 'perl ./misc/cronjobs/overdue_notices.pl'
=> You will see that only one message had been created. Its content shows both B2 and B3 overdue items
=> The sender address matches B1 address (the patron home library).
15. Search for OverdueNoticeFrom in System preferences and select cron
16. from cli run './misc/cronjobs/overdue_notices.pl --frombranch patron-homebranch'
=> you will get the same result at step 14
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Hinemoea Viault <hinemoea.viault@inlibro.com>
Was failing the qa script, so I perltidied the changed lines.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
Sometimes librarians fail to find an item on the shelf for a hold and need to mark the item as lost. In these cases it would be helpful to link the barcode to the item's "more details" form in the same way we do for the standard details item barcode hyperlink.
Test Plan:
1) View the holds queue, note the item barcode is not a hyperlink
2) Apply this patch
3) Reload the page, note the item barcode is a hyperlink to the more
details page for that item!
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There is no need for this code to have a hard coded list of fields directly in the code.
Any invalid keys would be skipped anyway.
If we refactor this code then adding new fields will be much simpler.
Test Plan:
1) Set up your MARCItemFieldsToOrder, verify everything is working
2) Apply this patch
3) Restart all the things!
4) Verify there has been no change to the MARCItemFieldsToOrder
functionality
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adjusts the logic so that we check:
1 - If there are less than 2 stages we disable the 'Move to next stage' button
2 - If the item is not in transit, we show move to next normally
3 - If the item is in transit (and there is more than 1 stage) the button is enabled with a note about transfer
To test:
1 - Setup a rota with multiple stages
2 - Add an item
3 - Advance to next stage
4 - Observe 'Move to next stage' button is disabled
5 - Check item in at destination
6 - Reload rota - observe 'Move to next stage' is enabled
7 - Apply patch
8 - Click 'Move to next stage'
9 - Note button is not disabled
10 - Hover and confirm note about transit
11 - Click 'Move to next stage'
12 - Checkin item at wrong branch, confirm it is correctly directed to correct stage
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1) Select a patron A
2) Change all the message prefs away from defaults.
3) Run misc/maintenance/borrowers-force-messaging-defaults.pl --doit --message-name Item_due
Verify that patron A prefs changed only for 'Item due'
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Resolve FIXME in sub _get_domain_count by using new logic
from bug 33837.
Test plan:
Run t/db_dependent/Koha/Notice_Util.t.
This triggers the _get_domain_count call using the filter.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Perltidied one line in cleanup_database.pl.
Bug 33837: Perl tidy block in Objects.t
WARN t/db_dependent/Koha/Objects.t
WARN tidiness
The file is less tidy than before (bad/messy lines before: 319, now: 320)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Instead of passing days and days_inclusive, this patch adds
min_days as replacement. Since days_inclusive is not widely
used, this can be done easily. It removes the confusion
whether days_inclusive impacted other parameters or not.
Test plan:
Run t/db_dependent/Koha/Objects.t
Run t/db_dependent/Koha/Old/Checkouts.t
Run t/db_dependent/Koha/Patrons.t (verifying the change in the
Koha::Patrons module for filtering by expiration date).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run t/db_dependent/Koha/Objects.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run t/db_dependent/Koha/Objects.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Verify that filter_by_last_update still works as expected by
running cleanup_database.pl with --messages DAYS parameter.
Look at the oldest messages.message_date (or insert one).
Run with -days X where today - X is before that date.
Run with -days Y where today - Y is just after it.
Note: misc/cronjobs/cleanup_database.pl -confirm -messages -1 -v
will remove all messages including one you inserted just now.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Setting the new preference to 1 will allow us to keep the
current behaviour on update. The library can then actively
decide to increase the number to whatever they prefer.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Tidied the atomicupdate file.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This retains the "last patron" link, but extends it to add a dropdown
containg the last 10 patrons.
A future enhancement to control how many patrons to retain would
complement this well.
1) Enable showLastPatron
2) Visit two patrons details pages
3) Note "Last patron" link displays and links to the last visited patron
4) Log out
5) Apply this patch
6) Log in
7) Visit the patron details page for a few patrons
8) Note the "Last patron" link behaves as is did previously
9) Note the split button has a pulldown with the other previous patrons
10) Verify that only the last 10 patrons are retained in the pulldown
11) Verify that if you visit a patron who is already in the list
they get moved to the top of the list
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an 'Alert subscriptions' tab to the patron's account on the OPAC, so they can easily view or cancel email alerts they have subscribed to.
To test:
1. Subscribe to email alerts for one or more subscriptions via the OPAC
2. Go to your account, notice the new 'Alert subscriptions' menu option, click here
3. Confirm your subscribed alerts show here. Confirm the table sorting works etc (JS enabled).
4. Test unsubscribing from email alerts, make sure the confirmation pop-up works as expected (JS enabled).
5. Confirm that, when unsubscribing, you are redirected back to this page.
6. Confirm the menu option disappears from the left sidebar navigation if you have no alert subscriptions.
Sponsored-by: Bibliotheksservice-Zentrum Baden-Wuerttemberg
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This enhancement adds an 'Alert subscriptions' page to a patron account to easily view or cancel email alerts the patron has subscribed to.
To test:
1. Go to Cataloging. Create a biblio.
2. Go to Tools -> Notices & slips. Create a notice under the "Serials (new issue)" module, if you don't already have one.
3. Go to Serials. Create a subscription. Link the biblio you just created. Add info like the callnumber, location, library. Choose your notice under Patron notification. Fill out the remaining details and save your subscription.
4. Open this record in the OPAC. Under the Subscriptions tab, click the button to "Subscribe to email notification on new issues"
5. Go back to the staff interface. Go to your patron account.
6. Notice there is a new "Alert subscriptions" tab in the left sidebar menu. The number in brackets should say 1, for the subscription you just enabled email alerts.
7. Click into the page. Confirm your subscription shows in the table.
8. Click the button to unsubscribe. A confirmation should pop up. Confirm you can cancel the unsubscribe action. Then confirm you can unsubscribe using this button.
9. Confirm tests pass t/db_dependent/Koha/Patron.t
Sponsored-by: Bibliotheksservice-Zentrum Baden-Wuerttemberg
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Like filter on category Bug 19454, it would be helpful to filter on a specified library for misc/maintenance/borrowers-force-messaging-defaults.pl
Test plan:
1) Select two patrons A and B in say libraries L1 and L2.
2) Change the msg prefs for A and B away from defaults.
3) Run misc/maintenance/borrowers-force-messaging-defaults.pl -doit -library L1
Verify that patron A changed and patron B did not.
4) Run with both category and library filters
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This change removes the no_batch_alters option.
When working with real world databases, you really want to use batch
alters to group together changes. Otherwise, the output becomes
too overwhelming/unwieldy.
On real world databases, I'm noticing big discrepancies, although
I think most of the time this is a difference in the collation
at the column level.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This script can take a connected database handle and compare that database
schema against kohastructure.sql to see what changes the database would
need in order to match kohastructure.sql
NOTE: It uses SQL::Translation::Diff, which is installed with DBIx::Class.
WARNING: The diff doesn't seem to compare comments, so that difference
won't appear in the output. If we wanted, we could easily enhance the
audit_database.pl script to also compare comments.
WARNING: The output is a proposed series of SQL commands. While they
are useful to review, they won't always duplicate the changes done
by updatedatabase.pl, so it's important to carefully analyze the output.
The key purpose of this audit script is to just highlight the differences
between the two.
Test plan:
0. Apply patch
1. vi ./installer/data/mysql/kohastructure.sql
2. Comment out some columns, change NULL status, or whatever you like
3. perl misc/maintenance/audit_database.pl \
--filename /kohadevbox/koha/installer/data/mysql/kohastructure.sql
4. Note that the output includes SQL commands to change the database
to match the new kohastructure.sql
5a. Try using koha-foreach and note that the database name appears above
the database comparison
5b. koha-foreach "perl misc/maintenance/audit_database.pl \
--filename /kohadevbox/koha/installer/data/mysql/kohastructure.sql"
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
- Added missing filter to template variable
- Correct spelling in atomicupdate
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a new system preference, DefaultAuthorityTab.
When set, this will choose the default display on the authorities details
page.
To test:
1 - Apply patch, update database
2 - View an authority detail
3 - You should default to the 0XX or first tab
4 - Set DefaultAuthorityTab to a number that there is no tab for in your authority
5 - Reload and verify details page loads the first tba
6 - Set DefaultAuthorityTab to 1XX or another tab that exists in your record
7 - Reload the details and confirm the correct tab is selected
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Adds LOST pull downs to 2 more preferences.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the system preferences interface so that preferences
which ask for a single authorized value can offer a dropdown menu of
choices instead of a text field.
The patch also updates a few existing preferences to use the new
feature: BundleLostValue, BundleNotLoanValue, and
ClaimReturnedLostValue.
To test, apply the patch and restart services.
- Go to Administration -> System preferences and search for "authorized
value."
- The search results should include the entries for BundleLostValue,
BundleNotLoanValue, and ClaimReturnedLostValue.
- Confirm that the dropdowns show the correct authorized value category
(LOST or NOT_LOAN)
- Confirm that setting or unsetting each of the preferences works
correctly.
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>
I've seen several places in which a syspref is retrieved and then
splitted using split and the fact they are pipe-separated strings.
It seems it would be simple (and handy) to add a method to do that.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/Context.t
=> SUCCESS: Tests pass, a pipe-separated syspref is correctly retrieved
as an arrayref.
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
Test plan:
1. Run tests
sudo koha-shell <instancename>
prove t/db_dependent/Circulation/issue.t
Sponsored-By: Waikato Institute of Technology, NZ
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
