This patch adds the ability to define password_expiry_days for a patron
category.
When defined a patron's password will expire after X days and they will
be required to reset their password. If OPAC resets are enabled for the
catgeory they may do so on their own, otherwise they will need to
contact the library
To test:
1 - Apply patch, updatedatabase
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 - Confirm their password_expiration_date field is set
SELECT password_expiration_date FROM borrowers WHERE borrowernumber=51;
5 - Create a new patron, do not set a password
6 - Confirm their password_expiration_date field is NULL
7 - Update the patron with an expiration to be expired
UPDATE borrowers SET password_expiration_date='2022-01-01' WHERE borrowernumber=51;
8 - Give the borrower catalogue permission
9 - Attempt to log in to Straff interface
10 - Confirm you are signed out and notified that password must be
reset
11 - Attempt to sign in to OPAC
12 - Confirm you are signed out and notified password must be reset
13 - Enable password reset for the patron's category and perform a
password reset
Note: you will have to find the link in the message_queue unless
you have emails setup on your test environment
SELECT * FROM message_queue WHERE borrowernumber=51;
14 - Confirm that you can now sign in and password_expiration_date field
is set 10 days in the future
15 - Expire the patron's password again
16 - Change the patron's password via the staff interface
17 - Confirm they can sign in and the expiration is updated
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>
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>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
This patch adds the capability to override minPasswordLenth and RequireStrongPassword settings by category
To test:
1. koha-shell kohadev
2. koha-mysql kohadev
3. drop database koha_kohadev;
4. create database koha_kohadev;
5. go to admin page and start webinstaller. There continue the steps until onboarding.
6. reach step 3 of onboarding and create a new administrator patron
CHECH => Password control woks as normal (Minimum length 3 and strong required)
7. finish Koha installation and enter admin with your new administrator
8. set minPasswordLength to 3 and RequireStrongPassword to “Don’t require”
9. Create a new category (CAT2 from now on.. CAT1 is the category you made in onboarding process) and set minimum password length to 8 and require strong password
10. Create two new patrons, one with CAT1(patron1) and one with CAT2 (patron2)
CHECK => In both cases, try different combinations of length and strength. For patron1 the only requirement is to have 3 letters, but for patron2 the minimum length will be 8 and will require strong password.
CHECK => Try changing patron category before saving. Password requirements will change with category change.
11. Edit CAT1 and set minimum password length to 5
12. Go to patron1 details page, and change password.
CHECH => Now password minimum length is 5, but still it doesn’t require strong password
13. Edit CAT1, leave blank minimum password length and set require strong password to yes.
14. Go to patron1 details page, and change password.
CHECH => Password minimum length is back to 3, but now strong password is required
15. Set minimum password length in CAT2 to 12.
16. Go to patron2 details page, and click to fill a random generated password
CHECK => generated password should be 12 characters length
17. Set PatronSelfRegistration to Allow in admin settings
18. Go to OPAC and fill self registration from.
CHECK => Play with patron category. For each change in category, password requirements are modified.
CHECK => Set CAT1 as patron category, set ‘aA1’ as password (or another valid password for CAT1) and before hitting submit button, change to CAT2. Form should enter invalid state, and CAT2 password requirements should be displayed as error in password input.
19. Create a patron for CAT1 and another for CAT2, leaving password blank
CHECK => For CAT1’s patron, generated password length is 8 (minimum length for generated passwords), but for CAT2’s patron should be 12
20. In admin set PatronSelfRegistrationVerifyByEmail to require
21. Fill self registration form again with CAT2 as category
CHECK => Password requirements works as previous case.
22. Leave password blank and click submit
23. select * from message_queue;
24. Copy the link in the message and paste it in OPAC
CHECH => Generated password is 12 characters long. (Copy user id for next steps)
25. In admin set OpacResetPassword to Allow
26. Go back to OPAC, reload and click on “Forgot password?” link
27. Paste user id and click submit
28. Repeat steps 23 and 24
CHECK => Info message says “Your password must contain at least 12 characters, including UPPERCASE, lowercase and numbers.”
CHECK => enter an invalid password and you’ll get the same message in warning.
29. Login OPAC with the last user and your newly created password
30. Go to “Change your password” option
CHECK => Info message says “Your password must contain at least 12 characters, including UPPERCASE, lowercase and numbers.”
CHECK => enter an invalid password and you’ll get the same message in below “New password” input.
31. prove t/db_dependent/AuthUtils.t t/db_dependent/Koha/Patron/Category.t
32. Sign off
Sponsored-by: Northeast Kansas Library - NEKLS
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
This patch adds the ability to exclude patrons (by category) from local
holds, and items, by editing the item itself or by batch item
modification tool.
To test:
1. apply patches
2. updatedatabase
3. Enable LocalHoldsPriority preference, and leave
LocalHoldsPriorityPatronControl in pickup library, and
LocalHoldsPriorityItemControl in holding library.
4. Search for a biblio with one item.
5. Place a hold with a patron (patron1) and set pickup location to a different
library of the item's home library
6. Place another hold with another patron (patron2) and set pickup location to be
the same as the item's home library
7. ./misc/cronjobs/holds/build_holds_queue.pl
8. Go to circulation -> holds queue
9. Search by the item's home library
CHECK => only the hold for patron2 (with the pickup location the same as the
item's home library) appears in the table
10. Go back to the biblio details page and click on "Items" tab
CHECK => There is a new section in the item's details between "Statuses"
and "History" called "Priority"
11. Set exclude to "Yes" and update
12. repeat steps 7 to 9
SUCCESS => only the hold for patron1 now appears, even the other hold had local
hold priority
13. Repeat step 10 and 11 but this time set exclude to "No"
14. repeat steps 7 to 9
CHECK => the hold for patron2 is back
15. Edit patron2's category and set exclude from local holds priority to
"Yes"
16. Repeat steps 7 to 9
SUCCESS => the hold for patron1 is back
17. Go to tools -> Batch item modification and in barcode list place
several (existing) barcodes and press continue
CHECK => There is a new section in the bottom called "Priority"
18. Set exclude to "Yes" and save
SUCCESS => all items in the list now have exclude setted to "Yes"
19. Try to checkout the first item to a patron3
SUCCESS => Alert message appears saying that patron1 has a hold on that
item
20. Click on Yes and then checkin that item
SUCCESS => There is a modal window saying that a hold was found for
patron1
21. prove t/db_dependent/HoldsQueue.t t/db_dependent/Holds/LocalHoldsPriority.t
22. Sign off
Sponsored-by: Cooperative Information Network (CIN)
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the staff interface handle the new flag when editing
the categories. I didn't add the flag to the list of categories table
because it makes it too big, but can be easily added if required by
users or QA.
To test:
- Along with other patches from this bug, edit patron categories
=> SUCCESS: Notice the changes are correctly stored
- Sign off :-D
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes the templates relying on the OpacResetPassword syspref
use the introduced TT plugin method instead by changing:
[% IF Koha.Preference('OpacResetPassword') %]
=>
[% IF Categories.can_any_reset_password %]
To test:
- Verify that all the places in which the 'forgot password' link is
displayed in OPAC keep working, provided there's at least one category
that has the flag set
- Attempt to recover the password for a patron that belong to a valid
category (i.e. that has the flag set)
=> SUCCESS: You can go through the normal process
- Attempt to recover the password for a patron that belongs to a
category with the flag unset.
=> SUCCESS: Once Koha identifies your category, you are told you are not
allowed to do it
- Sign off :-D
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes the staff interface handle the new flag when editing
the categories. I didn't add the flag to the list of categories table
because it makes it too big, but can be easily added if required by
users or QA.
To test:
- Along with other patches from this bug, edit patron categories
=> SUCCESS: Notice the changes are correctly stored
- Sign off :-D
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
So far the administration module only allowed for 2 permissions:
- circulation conditions (manage_circ_rules)
- everything else (parameters_remaining_permissions)
With this patch almost every section of the administration page
will have its own granular permission.
To test:
- Create different staff users:
1) One with parameters_remaining_permissions
2) One with parameters
3) One with catalogue and no parameters
4) One superlibrarian
- Apply the patch
- Run the database update
- Check the staff users:
1) All subpermissions, but manage_circ_rules
should be checked
2) Nothing should have changed
3) manage_item_serach_fields shoudl be checked
(page had catalogue permission before)
4) Nothing should have changed
- Try different settings of the permissions and
verify that
- Administration page behaves correctly
- Administration menu behaves correctly
! You shoudl only see what you have permission for
https://bugs.koha-community.org/show_bug.cgi?id=14391
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
New feature: provide granular means to configure warnings about items
that have been issued to a particular borrower before, according to
their checkout history.
- Global syspref ('CheckPrevCheckout'), set to 'hardno' by default,
allows users to enable this feature library wide.
- Per patron category pref allows libraries to create overrides per
category, falling back on the global setting by default.
- Per patron pref allows switching the functionality on at the level
of patron. Fall-back to category settings by default.
* Koha/Patron (wantsCheckPrevCheckout, doCheckPrevCheckout): New
methods.
* C4/Circulation.pm (CanBookBeIssued): Introduce CheckPrevCheckout
check.
* admin/categories.pl: Pass along checkprevcheckout.
* koha-tmpl/intranet-tmpl/prog/en/modules/admin/categories.tt: Expose
CheckPrevCheckout per category setting.
* koha-tmpl/intranet-tmpl/prog/en/modules/preferences/patrons.pref:
Expose CheckPrevCheckout syspref.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt:
Expose per patron CheckPrevCheckout preference.
* koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt: Expose
per patron CheckPrevCheckout preference.
* koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt: Add
'CHECKPREVCHECKOUT' confirmation message.
* installer/data/mysql/kohastructure.sql: Modify structure of
'categories', 'borrowers', 'oldborrowers'.
* installer/data/mysql/sysprefs.sql: Add 'CheckPrevCheckout'.
* installer/data/mysql/atomicupdate/checkPrevCheckout.sql: New file.
* t/db_dependent/Patron/CheckPrevCheckout.t: New file with unit tests.
Test plan:
- Apply patch.
- Run updatedatabase.
- Regenerate Koha Schema files.
- Run the unit tests.
- Verify 'CheckPrevCheckout' is visible in Patrons sysprefs and can be
switched to 'hardyes', 'softyes', 'softno' and 'hardno'.
+ Check out previously checked out items to a patron, checking the
message appears as expected.
- Verify no 'Check previous checkouts' setting appears on the borrower
category pages if the syspref is set to a 'hard' option.
- Verify 'Check previous checkouts' setting appears on the borrower
category pages and can be modified per borrower category.
+ Issue previously issued items to a borrower, checking the message
appears as expected (This setting should override the default
setting if that is set to a 'soft' option).
- Verify no 'Check previous checkouts' setting appears on the individual
borrower pages if the syspref is set to a 'hard' option.
- Verify 'Check previous checkouts' setting appears on individual
borrower pages and can be modified.
+ Issue previously issued items to a borrower, checking the message
appears as expected (This setting should override the category
setting and the default setting if the latter is set to a 'soft'
option).
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Attempting to set an "Until date" date for "Enrollment period" will
result in the date being accepted but not saved.
Test Plan:
1) Attempt to set an enrollment period until date for a new patron category
2) Note the period is not saved
3) Apply this patch
4) Attempt to set the enrollment period date again
5) This time it should save!
Signed-off-by: Andrew Brenza <abrenza@audubonlibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The 'borrower' should not be used anymore, especially for new code.
This patch move files and rename variables newly pushed (i.e. in the Koha
namespace).
Test plan:
1/
git grep Koha::Borrower
should not return code in use.
2/
Prove the different modified test files
3/ Do some clicks in the member^Wpatron module to be sure there is not
an obvious error.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described. Tested with Circulation, Members/Patrons, Discharge,
Restrictions modules and the must common functionalities
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jesse Weaver <jweaver@bywatersolutions.com>
This patch fixes the filename categorie.pl correcting it by categories.pl
The plurial is usually used for script names in the admin module.
Test plan:
Navigate to the patron categories page.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
No reference to categorie.pl anywhere in the code
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
