In which case do we pass category_type to this script? Am I missing
something?
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
== Test plan ==
1. Apply all patches
2. Create a new patron in a given category
=> Form show the dropdown with the selected category
3. Edit again
=> Value is kept
4. Edit a category to give it specific values for: messaging prefs,
password strength/length, can be guarantee
5. Edit the patron, change the category, and confirm that the different
limitation are correctly applied.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch prepends the credit_type_code and debit_type_code with
CREDIT_ and DEBIT_ respectively when doing a lookup on the notice letter
code.
Test plan
1) As previous patches, however instead of just naming your notice to
match the credit_type_code or debit_type_code use
CREDIT_credit_type_code and DEBIT_debit_type_code respectively.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a check for a more specific ACCOUNT_DEBIT template
(named to match the debit_type_code of the credit line) prior to
falling back to the ACCOUNT_DEBIT template.
Test plan
1/ On a patrons account page use the print option on a series of debit
lines with differing credit types (Overdue, Payout)
2/ Note that the same template 'ACCOUNT_DEBIT' is used for all types
3/ Apply the patch
4/ Run step 1 again and note all still print using ACCOUNT_DEBIT
5/ Add a new notice template under the 'circulation' module with a code
that matches one of your account debit types (OVERDUE, PAYOUT)
6/ Run step 1 again and note that where you have added a specific notice
for that debit type it has been used.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a check for a more specific ACCOUNT_CREDIT template
(named to match the credit_type_code of the credit line) prior to
falling back to the ACCOUNT_CREDIT template.
Test plan
1/ On a patrons account page use the print option on a series of credit
lines with differing credit types (Payment, Lost Item Return, Writeoff)
2/ Note that the same template 'ACCOUNT_CREDIT' is used for all types
3/ Apply the patch
4/ Run step 1 again and note all still print using ACCOUNT_CREDIT
5/ Add a new notice template under the 'circulation' module with a code
that matches one of your account credit types (PAYMENT, WRITEOFF,
LOST_FOUND)
6/ Run step 1 again and note that where you have added a specific notice
for that credit type it has been used.
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the display of the renewals modal when appropriate. A
"View" link is displayed next to renewals count where appropriate.
Clicking the link opens the modal that displays the logged renewals.
Sponsored-by: Loughborough University
Signed-off-by: Myka Kennedy Stephens <mkstephens@lancasterseminary.edu>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Ben Veasey <B.T.Veasey@lboro.ac.uk>
Rescued-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
I rescued this patchset by squashing previous work and updating it to
utilise the new renewals API routes introduced in bug 30275.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The code that populates the patron messaging preferences on initial form load
expects to have a category selected. Currently we only have one if one was
passed to the form. When creating an account from a parent, we don't have a
category explicitly selected - so we can just select the first of the possible
categories
To test:
1 - In KTD set 'Juvenile' category to have some messaging preferences
2 - Find a patron, say Edna Acosta, and 'Add guarantee'
3 - In new form preferences are blank, cancel
4 - Apply patch, restart all
5 - Go to Edna, click 'Add guarantee'
6 - Preferences are populated!
7 - Cancel
8 - Go to 'Patrons' module
9 - Click "+ New patron"
10 - Confirm messaging preferences load correctly when not adding child
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This enhancement shows recalls ready for pick-up on the patron's account
so they can't be missed.
To test:
1) Enable the UseRecalls system preference and set up your
recalls-related circulation rules.
2) Check out an item to Patron B.
3) Log into the OPAC as Patron A and search for the item.
4) Place a recall on that item. Note the pickup library.
5) Go back to the staff client. At the top right of the page, confirm
your logged in library matches the recall pickup library. Set the
library to the recall pickup library if needed.
6) Check in the recalled item and confirm the recall as waiting for
Patron A.
7) Go to Patron A's account (members/moremember.pl). Confirm the recall
shows under 'Recalls waiting here' and all the information is correct.
8) Go to Patron A's checkouts (circ/circulation.pl). Confirm the recall
shows under 'Recalls waiting here' and all the information is correct.
9) Click on the menu at the top right of the page and choose 'Set
library'. Change the library to some other library.
10) Repeat steps 7 and 8, however this time the recall should show under
'Recalls waiting at other libraries'.
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1/ Add 'Email' to the 'SMSSendDriver' system preference.
2/ Make sure 'EnhancedMessagingPreferencesOPAC' and 'EnhancedMessagingPreferences' are turned on.
3/ Add some SMS providers (/cgi-bin/koha/admin/sms_providers.pl) with different names.
4/ Notice on memberentry.pl and opac-messaging.pl the SMS providers sort by when they were added, not alphabetically.
5/ Apply patch and restart services.
6/ Look at memberentry.pl and opac-messaging.pl and notice that they SMS providers now sort alphabetically.
Signed-off-by: George Williams <george@nekls.org
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The C4::Suggestions::SearchSuggestion subroutine is badly written and
can be replaced by calls to Koha::Suggestions->search.
The hard part in this patch is suggestion.pl, the other occurrences have
been replaced easily.
Test plan:
The idea is to test the whole suggestion workflow.
1. Create a suggestion on OPAC
2. Create a suggestion on the staff interface
3. Edit suggestions
4. Filter suggestions (use the different filters and "organize by"
values)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Remove SearchSuggestion tests
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: (QA follow-up) Save some DB queries
This patch makes the suggestion-related pages rely on array size instead
of querying the DB each time they need to. In the case of
suggestion/suggestion.pl it goes from 4 COUNT(*) to 1.
To test, with KTD:
1. Run on the host machine:
$ docker exec -ti koha_db_1 bash
$ mysql -ppassword
> SET GLOBAL general_log_file='/var/log/mysql/mycustom.log';
> SET GLOBAL log_output = 'FILE';
> SET GLOBAL general_log = 'ON';
> \q
$ tail -f /var/log/mysql/mycustom.log | grep suggestions
2. Visit the different pages changed on this bug
=> SUCCESS: Some queries
3. Apply this patch
4. Repeat 2
=> SUCCESS: Less queries!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Fix branchcode and budgetid filtering
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Fix conflict with bug 28941
Well, this patchset fixed the security bug...
Redoing on top of bug 28941
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: (follow-up) Missing semicolon
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: Fix 'all' libraries
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 23991: (follow-up) Add value to filter_archived
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
JD Amended patch: squashed and edited commit message
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1) Have some patron categories that can and cannot be guarantee
2) Visit a patron's account and click the "Add guarantee" button
3) In the "category" dropdown, note that all categories are available
4) Apply this patch
5) Repeat step 2 and 3; the dropdown now only contains the categories
for which "can be guarantee" is set to "Yes".
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds a new field "Can be guarantee" to patron categories so it
becomes possible for any category type to have a guarantor.
To test:
1) Have a patron category of type 'Adult' and one of type 'Child'
2) Confirm, by searching for the "Patron guarantor" fieldset in the
edit/create form, that:
=> a patron of the first category can't have a guarantor
=> a patron from the second category can
3) Apply patch and run updatedatabase.pl
4) Edit the categories and note the new "Can be guarantee" field
5) It should have been set to "yes" for the "Child" and to "no" for
the "Adult"
5) Repeat step 2. It should behave in the same way.
6) Edit the "Can be guarantee" for any of the category and check
that the fieldset only appears when "Can be guarantee" is set to "yes"
7) prove t/db_dependent/Patrons.t
=> tests should still pass
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the member-flags template to use the patron-title.inc
include wherever patron names are referenced.
Test plan
1) Navigate to a patron and click through to their accounts tab
2) Note how the patron name displays in the title, breadcrumb and
headings
3) Click through to make a payment
4) Note how the patron name displays in the title, breadcrumb and
headings
5) Apply the patch and reload the page
6) Confirm the patron name still appears in each location and is
consistently formatted and linked as you would expect
Note: This patch also removes a superflous hidden title form element
that was simply passed to and from the controller but not actually used
in any way.
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>
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>
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>
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>
This patch updates the output_and_exit call to instead pass an error
parameter in the template and use it to display the warning instead of
the rest of the page content in the 'Manage two-factor authentication'
page.
This allows for translation and makes the page adhere to normal
practices.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Script prints a warning.
Module raises an exception.
Unit test added.
Test plan:
Run t/db_dependent/Koha/Encryption.t
Run t/db_dependent/Koha/Auth/TwoFactorAuth.t
Remove entry and check script.
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>
Chose here to fall back to $patron->queue_notice. Which is tested
already, so removing the additional test code.
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: Fridolin Somers <fridolin.somers@biblibre.com>
When registering or deregistering, send a confirmation.
Test plan:
Register or deregister with patron having email address.
Verify that you got a confirmation mail.
Run t/db_dependent/Koha/Auth/TwoFactorAuth.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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
Deregister 2FA for patron.
Check if secret is empty in borrowers.secret.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test updated accordingly.
Adding utf8 flag to CGI in staff script.
Test plan:
Run t/db_dependent/Koha/Auth/TwoFactorAuth.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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Instead of using deprecated Google Charts API, and exposing our
secret in a GET parameter, we generate QR data ourselves.
Test plan:
[1] Enable two factor authentication in the prefs.
[2] Login in staff. Go to account. Select Manage 2FA.
[3] Verify that QR code is displayed.
[4] Register the QR in your authenticator app and test 2FA
by logging in again.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with Google Authenticator and FreeOTP.
Bug 29873: (follow-up) Rename qr_dataurl
As requested by a QA team member.
We're moving to qr_code as method name. This is the same name as
the method in the underlying base class.
Apart from one sed statement, changing to self->SUPER on one line.
Test plan:
Can you still register, logout and login?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 29873: (follow-up) Switch to GD
We do not need a new module, we could use GD instead.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We're doing this in the registering stage and at disabling.
Test plan:
Ënable two-factor auth but logout/login on another tab. You should
get the Wrong CSRF token when submitting.
Do similar thing while disabling.
Verify that you can register / disable when in the same session.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
FAIL members/two_factor_auth.pl
FAIL file permissions
File must have the exec flag
FAIL koha-tmpl/intranet-tmpl/prog/en/modules/members/two_factor_auth.tt
FAIL filters
missing_filter at line 42 ( <p>Account: [% issuer %]</p>)
missing_filter at line 43 ( <p>Key: [% key_id %]</p>)
missing_filter at line 54 ( <input type="hidden" name="secret32" value="[% secret32 %]" />)
missing_filter at line 58 ( <img id="qr_code" src="[% qr_code_url %]" />)
FAIL Koha/Auth/TwoFactorAuth.pm
FAIL pod coverage
POD is missing for 'new'
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 'Send welcome email' option to the 'More' dropdown
menu in the patrons toolbar.
Clicking the button will queue the welcome email again for the patron and
redirect the user to the Notices tab to view it's contents.
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Jessie Zairo <jzairo@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch replaces the AutoEmailOpacUser system preference with a new
AutoEmailNewUser preference. This makes the functionof the preference
clearer.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates all references to the former ACCTDETAILS notice to
use the new WELCOME email notice instead.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Regression from bug 30063. If you are searching all patrons (not search term passed) from the header, the patron search result is not displayed.
Test plan:
Go to the Koha homepage, search patrons, don't enter a search term and
click "submit"
All patrons must be returned.
Regression test: on the other patron search forms, confirm that there is
no regression, ie. no patron displayed until you search for something
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To test:
* Length menu (PatronsPerPage)
* Query description
* Highlight of the current library
* sticky header - Does not work (?)
If the table does not show when you submit the filter form, make sure
you regenerated the compiled CSS.
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
In this patch we want to reuse what has been done in the previous bug
report to search patrons using the REST API route.
The code is mainly in members/search.tt, for all the patron searches
that "add" or "select" a patron (popup windows).
The patron search for holds is a bit different, we don't want to open a
popup window.
We are moving to code to an include file (patron-search.tt) to make it
reusable easily.
Note that we are improving how the patron's addresses are displayed, and
provide a JS equivalent to the TT includes files.
Test plan:
Search for patrons from the "Place a hold on" view.
You should see the same view as behaviour, with more filters.
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Last patches remove the ability to search on extended attributes.
C4::Utils::DataTables::Members::search is searching on all the
attributes that are flagged as "searchable", we want to keep this
behaviour.
I have tried several things and this is the simplest I have found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
Select a manager for a suggestion
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch will rewrite some of our patron searches to make them use the
REST API routes (and so the powerful the DataTables wrapper which will
bring all the nice DT feature to filter, sort, etc.)
The patron searches we will take into account here are those that we use
to select a patron in a pop-up:
* Guarantor
* Suggestion's manager
* Patron's card
* Serial routing list
* Users to notify when order is received
* Manager of an acquisition basket
* Owner and users of a fund
Regarding permissions there are two main problematics:
* Filter a patron set by patrons having a
specific subpermissions (in case of adding a manager to a suggestion or
when we deal with acquisition and funds). We added a new
Koha::Patrons->filter_by_have_subpermission method that will take in
parameter a subpermission. To make thing transparent for the callers we
are adding new routes, like /suggestions/managers to list the possible
managers of suggestions.
* Restrict/allow access to the default patron searches /patrons
We need to access it when a logged in patron does not have borrowers
permission.
Ideally we need a separate "search_borrowers" subpermissions but it's
considered outside the scope of this change.
For each patch you will take care of testing the different permissions
that are into effect (either for the logged in patron or the patrons
returned by the search).
The tables should contain the same columns as prior to this patch,
except for "categories" and "library". We have the filter on top of the
page and so we need to add them to the table as new columns if they
weren't there before.
Test plan (for this patch):
Search for guarantor and select
Test plan (for all patches):
Add/Select patrons from the correct place where you can search for
patrons, play extensively with the filters/pagination/etc
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
moremember-patronimage.pl|tt were not needed.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch builds on a patch by Mark Tompsett, adding the option to take
a patron's picture using the computer's webcam. The photo can then be
saved to the patron's account.
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).
- Go to Administration -> System preferences and enable the
'patronimages' preference.
- View a patron record. In the sidebar, hover your mouse over the blank
patron image. Click the "Edit" button which appears.
- A modal window should appear with two sections, "Upload patron photo"
and "Take patron photo."
- If your computer has a webcam, your browser should ask permission to
access it. Grant access.
- You should see the view of your webcam shown under the "Take photo"
button.
- Click the "Take photo" button. The captured photo should be shown in
place of the live video from the webcam.
- You should now see three buttons: "Retake photo," "Download photo,"
and "Upload photo."
- Clicking "Retake photo" should hide those buttons and return you
to a live video view.
- Clicking "Download" should make your browser download the image.
- Clicking "Upload" should cause the page to redirect back to the
patron detail page where you should see the new patron image
displayed in the sidebar.
- Trigger the modal again and click the "cancel" button. The
modal should disappear and camera access should stop.
- If your computer has no webcam the modal should appear correctly but
there should be a banner at the bottom indicating that a camera is not
available.
- Try the test again but this time deny your browser access to the
webcam. You may need to reset the camera permissions in your browser's
settings. When the modal appears you should see a message saying
access to the camera is denied.
- The patron image edit modal should be available on all pages which
show the patron image in the sidebar: Check out, Batch check out,
Details, Accounting, Routing lists, Circulation history, Holds
history, Modification log, Notices, Statistics, Files, Purchase
suggestions, Discharges, Housebound, and ILL requests history.
- Test adding an image to a patron record using the "Upload photo"
option. It should still work correctly.
- If the patron has an image attached, the "Upload photo" section should
have a "Delete" button. Test that it works correctly.
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The original notice was sent using SendAlerts, which triggers
immediately on submission and doesn't wait for the cron task.
This patch restores that immediacy and also fixes a bug in the imports
on the original patch.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We actually have a Koha::Patron method to do all the work of finding the
right patron primary email address for notices.. we can use that here
instead of doing it long hand.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The ACCTDETAILS notice apparently bypasses message_queue; notices are sent directly to the linux mail queue.
Test Plan:
1) Apply this patch
2) Create a new patron with an email address
3) Note the patron's ACCTDETAILS notice shows in the patron's messages
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
