To test:
1. Apply patch
2. Have a bunch of invoices, some open and some closed.
3. Go to Home > Acquisitions > Invoices and do a search that will
return you many of those invoices, some open and some closed.
4. Notice the 'Select all' and 'Clear all' buttons.
5. Try clicking 'Select all' on the Open invoices tab. All Open invoices
should become checked.
6. Try clicking 'Clear all' on the Open invoices tab. All open invoices
should become unchecked.
7. Try 5 - 6 again but on the Closed invoices tab.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Update ternary for token timeout to use perl constants
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a check that the patron can reach the password reset
page using category.effective_reset_password which handles fallback to
OpacResetPassword system preference transparently.
Test plan
1) Set at least one patron category to dissallow patron password resets
2) Search for a patron of that category
3) Confirm the 'Send password reset' option no longer appears
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds the ability for staff with the edit_borrowers permission
to send password reset emails to users.
The staff initiated password reset has it's own notice,
STAFF_PASSWORD_RESET, and the reset link produced has an extended
timeout of 5 days, as apposed to the usual 2 day limit.
Test plan
1) Apply patch and run the database update
2) Login to the staff client with a user who has the 'edit_borrowers'
permission.
3) Note that a new, 'Send password reset' option appears under the
'More' menu on the patron details page.
4) Clicking the button will queue the STAFF_PASSWORD_RESET notice and
redirect the user to the Notices tab.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a new STAFF_PASSWORD_RESET notice template for password
recoveries initiated via the staff client as aposed for those initiated
by the end user.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Chmod 755 on atomic update file.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Note: Problem is that we cannot know if default was translated
or en contains the original notice. Actually this holds for
the other languages too. So this is an educated guess without
using the lang field.
Test plan:
Run db rev.
Trigger the warning by replacing Pages by PPages in an AR notice.
Run db rev again.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Note: It will be hard to update translated notices. If we cannot find
the part 'Pages:' then the replace does not do anything.
Test plan:
Run db rev.
Check an existing AR notice (English).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
Run a new install. Check the AR notices.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch corrects a typo in the <title> tag of the
overdue recalls template:
"Circulaion" corrected to "Circulation."
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch fixes the calendar.inc includes in both staff and OPAC in
order to remove a typo: An extra space in the check for the "dateformat"
system preference.
The result of this error is that changes to the dateformat system
preference will not be correctly applied to Koha without a restart.
To reproduce the problem start the process of creating a new patron.
- In the date of birth field, select a date. The format of the date
inserted should match your current dateformat system preference.
- Go to Administration -> System preferences and update dateformat to
something different.
- Go back to the patron creation form (refresh it if necessary).
- The hint under the Date of birth field will match your updated system
preference, but when you pick a date using the calendar widget it
will still be formatted according to the old value of dateformat.
To test the fix, apply the patch and run through the same steps above.
A change the dateformat preference should be immediately reflected in
the functionality of the calendar widget.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To test:
1 - Set a rule in UpdateItemLocationOnCheckin
2 - Enable cataloguing log
3 - Check in an item that will trigger a change
4 - Check the modification log for item - there is a cataloguing entry
5 - Apply patch
6 - Repeat
7 - No log!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Simple test to cover UpdateNOtForLoanStatusOnCheckin and UpdateItemLocationOnCheckin
to confirm the cataloguing log does not record these
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates SIP patron code to use account methods to calculate balances
over the patronflags returns. It also checks if patron should be blocked for each
'No Issues charge' preference
Tests are added for NoIssuesChargeGuarantees
To test:
1 - Set noissuescharge preference to 5
2 - Add a $10 charge to a patron
3 - perl misc/sip_cli_emulator.pl -a localhost -p 6001 -su term1 -sp term1 -l CPL -m patron_information --patron BARCODE
4 - Note the 64 message starts with Y's that mean patron is blocked
5 - Set noissuescharge to 11
6 - Repeat 3, patron is no longer blocked
7 - Set NoIssuesChargeGuarantees to 8
8 - Repeat 3, patron is blocked
9 - Pay $3 on patron so they owe 7
10 - Repeat 3, patron is not blocked
11 - Add a child account with patron as guarantor
12 - Repeat 3, patron is not blocked
13 - Add a $4 charge to child
14 - Repeat 3, patron is blocked
15 - Repeat 3, but with child barcode, child is not blocked
16 - Set NoIssuesChargeGuarantorsWithGuarantees to 10
17 - Repeat 3, patron is blocked
18 - Repeat 3 with child barcode, child is blocked
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
1. Configure the default MARC framework to use those value builders:
- unimarc_field_146a for 146$a
- unimarc_field_146h for 146$h
- unimarc_field_146i for 146$i
2. Verify that they all work correctly according to
https://www.ifla.org/files/assets/uca/unimarc_updates/BIBLIOGRAPHIC/u-b_146.pdf
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>
Running Auth.t produces several warnings like:
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 103.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 104.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 112.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 103.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 104.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 112.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 103.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 104.
Use of uninitialized value $name in hash element at /usr/share/koha/Koha/CookieManager.pm line 112.
Test plan:
prove t/CookieManager.t t/db_dependent/Auth.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Trivial fix. Before working on bug 29954.
Test plan:
Run a few tests like t/Context.t, t/db_dependent/Auth.t and
t/db_dependent/Circulation.t.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Odd number of elements in anonymous hash at C4/Letters.pm line 827.
Trivial fix. Adding undefined check on result to prevent warns
on that one.
No test plan. Read the patch.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes it so cash register reports puts branchcode from the
cash register where the payment was made into "Transaction library"
column instead of taking the branchcode of the manager.
Test plan:
1- Use cash registers (administration > system preferences > UseCashRegisters)
2- Create another library if you only have one (administration > libraries > new library)
3- Create a cash register in each library if they don't already have one (administration > cash registers > new cash register)
4- Create a fee on your own account and pay it right after in both libraries.
5- Go to reports > cash register and generate the statistics.
6- Notice "transaction library" in both rows are the same even though the fees were paid in two different libraries and two different cash registers.
7- Apply the patch and click submit to re-generate statistics
8- Notice it now shows the correct library where the transactions were done
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
After Bug 18936, in test suite, there is still t/db_dependent/Koha/IssuingRules.t and t/db_dependent/Koha/IssuingRules/
This patch moves IssuingRules.t inside CirculationRules.t and renames dir t/db_dependent/Koha/IssuingRules.
And adds DB transation in each first-level subtest.
Also renames in :
use constant GUESSED_ITEMTYPES_KEY => 'Koha_IssuingRules_last_guess';
Test plan :
Run prove t/db_dependent/Koha/CirculationRules.t
prove t/db_dependent/Koha/CirculationRules/*
prove t/db_dependent/Circulation/maxsuspensiondays.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch corrects the path of an image specified as the background to
a couple of elements in the OPAC. The incorrect path was causing 404
errors.
To test, apply the patch and rebuild the OPAC CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- If necessary, activate one or more cover image services in
Administration, e.g. OPACAmazonCoverImages, OPACLocalCoverImages,
and/or OpenLibraryCovers.
- In the OPAC, locate a bibliographic record which has a cover image
from one or more of the services you activated.
- On the detail page for that record, the cover should load correctly.
- In the browser console you should see no errors related to a file not
found: /opac-tmpl/bootstrap/img/spinner-small.gif
- In the browser console, submit this JavaScript snippet:
$(".cover-image").remove();
The cover image should disappear, revealing the "spinner" icon behind
it.
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>
This patch wraps the List RSS icon in a check on whether the list is
public. Private lists RSS can only be accessed by a logged-in patron.
To test apply the patch and view a public list in the OPAC. You should
see an RSS link icon next to the list title.
Now log in to the OPAC and view a private list. There should be no RSS
link.
Note the QA tool warning about the aria-hidden attribute is a false
positive. The parent element has a label.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If several terms are passed we should split them.
Test plan:
Search for "edna acosta" (without quotes) in the filters from the left
side of the main patron search
Do some regression tests
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We want to keep the default initComplete call to add/remove the
'disabled' class on the 'Clear filters' link.
Test plan:
Search for patrons, add something to the general DT search and confirm
that the 'Clear filters' link can be clicked (ie. is not disabled) when
the input field is not empty.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Agree that it does not look very elegant.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch corrects the is_valid_date function in the OPAC and staff
interface so that it work correctly with Flatpickr.
To test, apply the patch and clear your browser cache if necessary.
- In the staff client, locate a bibliographic record and edit its items.
- Test that the "Date acquired" date picker works correctly and that
there are no errors in the browser console.
- Test other date input fields to check that they still work, e.g.
specify due date during checkout; Catalog statistics wizard; Patron
entry/modification, etc.
- Perform similar tests in the OPAC: Hold suspension; Update your
personal details.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates letter.js so that it uses .prop("selected") to look
for selected <option>s instead of .attr("selected"). This is necessary
because of the jQuery upgrade.
To test, apply the patch and edit any notice. Test that you can select
one or more database columns and insert them into the body of a notice
by clicking "Insert." Confirm that your selections are inserted where
you left the cursor in the message textarea.
Test with multiple message transports and with multiple languages
installed (with TranslateNotices enabled).
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When search a patron for placing a hold, if a cardnumber is entered we
should pick the patron and use it, instead of display the table result.
This was a regression caused by bug 30063.
Test plan:
- Place a hold on anything in staff
- Search for 42 or any other existing cardnumber in your database
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On fixing the spec to have `format: date` I noticed the tests were
expecting explosions because of date handling not being done. The
OpenAPI plugin does this correctly when you set the format right.
So, I adapted the tests so they expect 400 and return the type error.
We don't usually add such tests (i.e. test the plugin does its job
correctly) but it doesn't hurt to keep them just in case something
really changes badly there (plugin bug?).
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the following changes to the spec:
* Password being the resource and expiration_date an attribute for it,
so reorganizing things and also renaming the route.
* Be it undefined or defined, expiration date is only one and thus
should use the PUT verb (as in overwrite).
* Minor bug 30194-related fixes.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To test:
1 - Sign in as a superlibrarian
2 - Tools->Batch patron modification
3 - Add patrons with and without pasword expiration set
4 - Confirm dates display correctly on modification page, or show never
5 - Check the box to delete all dates
6 - Confirm patrons now show 'Never'
7 - Edit patrons again, set a date
8 - Confirm date is set correctly
9 - Sign in as a user with catalogue/tools/borrowers permissions, but not superlibrarian
10 - Confirm y9ou do not see, and cannnot edit password expiration dates
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To test:
1 - Sign in as a superlibrarian
2 - Find a patron account with no password expiration set
3 - View member detials
4 - note expiration says 'Never'
5 - Edit patron
6 - Set patron expiration
7- Save
8 - View details, confirm password expiration shows correctly
9 - Sign in as non-superlibrarian
10 - Confirm you don't see expirationdate on details page
11 - Edit patron and confirm password expiration does not show
12 - Edit HTML and confirm you epxiration date not saved
<input type="text" name="password_expiration_date" value="2052-05-02">
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To test:
1 - prove -v t/db_dependent/api/v1/patrons_password_expiration.t
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a new page opac-reset-password where a user cna enter their login
(userid or carndumber), current password, and new password.
If the user has a password expiration date and the current password is correct and
the new passwords match and meet requirements their password will be updated and the
expiration date reset
A patron whose password does not expire will be reidrected to login to change their password
To test:
1 - Apply patch, updatedatabase, enable new syspref EnableExpiredPasswordReset
2 - Set 'Password expiration' for a patron category
Home->Administration->Patron categories->Edit
3 - Create a new patron in this category with a userid/password set, and an email
4 - Update the patron with an expiration to be expired
UPDATE borrowers SET password_expiration='2022-01-01' WHERE borrowernumber=51;
5 - Give the borrower catalogue permission
6 - Attempt to log in to Straff interface
7 - Confirm you are signed out and notified that password must be reset
8 - Click 'Reset your password' link
9 - You should see the reset password page with fields for: login, current password, new password, conmfirm password
10 - enter invalid/incomplete credentials
11 - Confirm you are notified of invlaid credentials
12 - Fill in all fields, but enter current password as new password
13 - Confirm you are notified of no change
14 - Set minimum password length / strong password requirement for category
15 - Confirm you receive error if new password too short or not secure
16 - Enter a valid new password and submit and confirm update is successful
17 - Confirm you have buttons to go to OPAC or Staff and that both work
18 - Confirm you cna log in (i.e. expiration has been reset)
19 - Expire the users password
20 - Remove catalogue permission
21 - Reset password again and confirm only OPAC link
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If the passed credentials are wrong, we shouldn't expose things like the
password is expired.
This patch takes care of that.
To test:
1. Have a known patron with password_expiration_date set so its
password is expired. Can be done like:
$ koha-mysql kohadev
> UPDATE borrowers \
SET password_expiration_date='2022-04-25' \
WHERE borrowernumber=132;
Note: change the borrowernumber
2. Attempt to login to the OPAC with wrong credentials
=> SUCCESS: You are rejected, with a message telling credentials are
wrong
=> FAIL: You are told the password is expired.
3. Apply this patch and restart Plack
4. Repeat 2
=> SUCCESS: You are rejected, credentials are wrong and no mention to
password being expired.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
- The atomicupdate didn't have "bug_number" defined.
- The "Your password has expired" message is now styled with the same
class as other OPAC login messages.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
