Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch makes the script pass the default SMTP transport to the
->send_or_die call.
The default is picked as this is the current behavior. New enhancements
could add the *library_id* to the message_queue table, and allow using
different transports depending on that. But it is out of the scope of
this bug.
To test:
1. Verify messages are being sent.
2. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
JD amended patch: revert
- unless $format =~ m[^html$|^csv$|^ods$];
+ unless $format =~ m/^html$|^csv$|^ods$/;
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The library usage is discouraged by the current maintainer and we don't
use it in the codebase anymore.
To test:
1. Apply this patch
2. Run:
$ git grep MIME::Lite
=> SUCCESS: No uses of the removed library
3. Sign off :-D
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch makes the cronjob script use Koha::Email and thus relying on
configured SMTP settings instead of just trying localhost.
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch makes searching for '%','_' and '\' work by escaping those
symbols in the query before sending them to the API.
To test:
1. Go to the cities page
2. Add two cities:
- 'Cordoba %'
- 'Buenos Aires _'
- 'London \'
3. Use the column search on the name, alternating _, \ and % as the query
=> FAIL: Weird behavior
4. Apply this patch and reload
5. Repeat 3
=> SUCCESS: Filtering works correctly!
6. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When building search results for XSLT we generate and pass a list of hidden
itemnumbers.
We do skip the lost items in our parsing, however, we neglect to add the itemnumber
to the hidden list
This patch simply adds the lost itemnumbers to the list
There is more work to be done here to simpliofy this process, however, this patch resolves
the issue and can be backported to stable branches
To test:
1 - Set systempreference hidelostitems to "Don't show"
2 - Edit a record to set one item as lost and one as available
3 - Perform an OPAC search that returns the record above
4 - Note that the lost item shows in availability line
5 - Click on the record - note the lost item does not show on details
6 - Apply patch
7 - Reload search results
8 - Lost itme no longer displays
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
1 - Define default messaging preferences for a patron category, checking a transport and the digest only boxes
2 - Create a new patron of a different category
3 - Change the category to the one set above
4 - Note that checkboxes are checked, but digest boxes are disabled
5 - Save patron - the digest boxes are not saved
6 - Apply patch
7 - Repeat 2&3
8 - Note checkboxes for digest are checked and enabled
9 - Save patron and confirm options are saved
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Having IndependentBranches on, a librarian who is not superlibrarian
does not get a autocomplete hint list when entering a part of the
patron's name (while performing check out, etc.) Koha registers
an error:
DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st
execute failed: Column 'branchcode' in where clause is ambiguous at
.../Koha/Objects.pm line 312
This is due to fix to the bug 10902 -- addig "prefetch => 'branchcode'" to
the attributes of the query in circ/ysearch.pl, while having branchcode
in the search parameters.
Test plan:
----------
1. Have IndependentBranches on, PatronAutoComplete set to 'Try.
Be a librarian without superlibrarian privileges. Have some
patrons defined.
2. In the main input field on the top, with Check out active, try to
put 3+ characters from the known user name/cardnumber etc. You
will get no hint.
3. Apply the patch.
4. Repeat 2. You should now see an autocomplete hint list.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
A check in should relocate a waiting hold under the current desk. But
the current behaviour when confirming the hold is to dismiss the
modal, the item is still attached to the preceding desk.
This patch mimicks the print and confirm behaviour to trigger the desk
change.
Plan test:
1. Add some desks to you library (syspref UseCirculationDesks and
Administration -> Patrons and circulation -> Circulation desks.
2. Set a desk in your session (Circulation -> Set library and desk)
3. Have some waiting hold attach to a desk (make a hold on a checked
out item and return it).
4. Change your current desk.
5. Check in again the item, click on confirm.
6. Go to the item notice detail, it appears as waiting at your first
desk.
7. Apply patch.
8. Check in again the item.
9. go to the item notice detail, it should appear at your current
desk.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Our objects.search helper is written for being used in our API
controllers, which get their query parameters processed by the OpenAPI
plugin, using JSON::Validator.
Particularly, the 'q' parameter is defined as 'multi' on our spec, which
means objects.search always gets it as an arrayref.
As the Objects.t tests are not using the OpenAPI plugin, a hashref is
generated as only one q= is being passed. This patch adds an extra
validation on objects.search, for the non-arrayref use case and does the
right thing.
To test:
1. Run:
$ kshell
k$ prove t/db_dependent/Koha/REST/Plugin/Objects.t
=> FAIL: Tests fail!
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass!
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
There are several occurrences of `my $var += ` or .= in the code.
It should not cause problems but it's confusing.
Test plan:
Read the patch and confirm that the changes make sense.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is a follow-up patch for bug 29543. If an invalid cardnumber has
been used we should not generate a token.
Test Plan:
1. Set SelfCheckoutByLogin to 'cardnumber'.
2. Go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
3. Enter an invalid carnumber like 'thisisabadcardnumber'
4. See the appropriate message "Sorry The userid thisisabadcardnumber was not found in the database. Please try again."
5. Try again with a different cardnumber and notice the same exact error message including the 'thisisabadcardnumber' cardnumber.
6. Apply this patch
7. Restart all the things!
8. Repeat steps 2-4
9. Try again with a different cardnumber, you should now see the correct
cardnumber!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We should not need this function any longer
I left the else conditional just in case
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch removes the alert, but adds a stopPropagation call
in order to not close the menu when the disabled buttons are clicked
To test:
1 - Find a record with items in the staff interface
2 - Click edit
3 - Note 'Edit items in a batch, 'Delete items in a batch', and 'Delete
all items' are grayed out
4 - Note hovering displays a note that there are no items
5 - Click on each anyway, an alert is generated, menu is closed
6 - Apply patch
7 - Reload page
8 - Click on each disabled option and confirm
- there is no more alert
- the menu does not close
9 - Confirm tooltip is displayed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In circ/overdue.pl, the Title column is the result of includes/biblio-title.inc display. The code of biblio-title.inc means to display subtitle, part_number and part_name from biblio table, but nothing but commas show up because those fields are never retrieved by overdue.pl
To reproduce:
1) have an item whose biblio.subtitle, part_name and part_number and non-empty.
2) issue it, then set it late (overdue).
3) go to the report page (circ/overdue.pl) and make it appear.
4) subtitle, part_number and part_name do not appear, although they are meant to by biblio-title.inc code
5) apply the patch and try again.
It's a simple fix of adding the fields in the database query.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If you are editing ES mappings and you use the DataTable filtering option,
the table won't contain all the mappings you have in the DB.
If the form is submitted they will be removed and data will be lost!
Test plan:
Edit ES mappings, filter and submit the form.
Confirm that the table are redrawn before the form submission which
prevent data loss
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch prefixes all of the fields in OpacHiddenItems with
"me." before searching.
Unit tests added to cover this case1
To test:
1 - Create a public list
2 - Set OpacHiddenItems to:
biblionumber: [1]
3 - Attempt to view list in OPAC
4 - Booom
5 - Aply patch
6 - Reload list
7 - Success
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
defining package as 'recommended', as suggested
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Speaks for itself.
Test plan:
Check if the acqui z3950 search works as expected.
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Remove the line without the scalar.
Test plan:
Just look at the 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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
1 - Find a record in the staff catalog
2 - Edit the record
3 - In the 520 notes field, add an ASCII escape character (27 decimal, 1b hex)
On ubuntu Ctrl+Shift+u, then 1b, enter
4 - Save the record
5 - Set syspref ShowComponentRecords to 'both...'
6 - On record details: New->New child record
7 - Save the record
8 - Attempt to view the parent record in the staff client and opac
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the use of jquery.cookie.js in the OPAC with the
newer js-cookie plugin. The patch adds the latest version of the
js-cookie library and removes the old jquery.cookie plugin.
To test, apply the patch and go to the advanced search page in the OPAC.
- Perform a search using a number of different limits and settings, e.g.
keyword, item type, and sort-by.
- On the search results page you should see at the top of the results
list a link to "Return to the last advanced search."
- The link should take you back to the advanced search page with all the
same settings filled into the form.
- A search with the "More options" view enabled in the advanced search
form should result in a link which returns to the "More options" view.
- Searching via the "quick search" form at the top of the page should
clear the cookies which were set in order to remember the advanced
search. See
https://developer.mozilla.org/en-US/docs/Tools/Storage_Inspector for
information on viewing your browser's stored cookies.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch updates the holds table to always insert a hidden input when a hold is 'found'
and covers the case where the hold is 'found' but doesn't match known statuses
To test:
1 - Place two holds on a record for two different patrons, with different pickup locations
2 - Check in one item at expected branch to set waiting
3 - Then either:
- Use batch modification or item editor to change the holding branch for the item
- Sign in to a different branch and manually transfer the item back to it's home location
4 - View the holds for the record
5 - Note the 'Pickup library' column is blank for that hold
6 - Change pickup location for other hold and press 'Update holds'
7 - Note the waiting hold is still blank, and now second hold has no pickup location
8 - Check the DB and note the first hold has had the pickup location changed
8 - Apply patch
9 - Delete holds and repeat 1-4
10 - Note the waiting hold now displays:
Hold expected at {Branch}, please checkin to verify status
11 - Change location for second hold and update holds
12 - COnfirm location chanegd correctly and first hold unaffected
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If a maximum number of checkouts allowed is defined in circulation
rules, C4::Circulation::TooMany will loop over all patron's checkouts.
When a patron has several hundreds of checkouts, it can really slow down
the checkout process by several seconds (or even tens of seconds)
This patch does two things:
- Always prefetch item data so that `$c->item` does not execute an
additional SQL query at every iteration of the loop. Item data is
always needed at the first line of the loop, so there is really no
downside for doing this.
- Build the `@types` array only once, out of the checkouts loop. Since
it does not depend at all on patron's checkouts data, it does not make
sense to build it inside the loop.
Test plan:
1. Before applying the patch, create a patron with a lot of checkouts.
I tested with 1000 checkouts, but the slowness should be noticeable
with less.
2. Make sure you have a circulation rule (one that apply to your patron
and the item(s) you will check out for testing) with a maximum number
of checkouts allowed
3. Check out an item for the patron with a lot of checkouts. Measure the
time it takes.
4. Apply the patch
5. Check out another item (or check in and then check out the same item
used in step 3). Measure the time it takes and compare it to step 3.
It should be faster now.
6. Run `prove t/db_dependent/Circulation/TooMany.t`
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch updates teh search customisations in ill-list-table to
properly fetch the existing flatpickr instances for date searches.
To test:
1. Have at least one ILL request on the ILL requests page
2. Open the broser inspector
3. Choose a date on the left hand form
=> FAIL: Errors in the console, search doesn't work
4. Apply this patch
5. Reload
6. Repeat 2-3
=> SUCCESS: No more errors, filtering works!
7. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 30098 fixed patron search behavior when a later page has only 1 result, but broke the redirect when there is only a single result from search.
To test:
1 - Perform a patron search that returns 41 results, on koha-testing-docker, 'a' works
2 - Go to second page of results, works
3 - On third page you remain in results and are not redirected
4 - Perform a patron search that return only 1 result, name or cardnumber
5 - You get redirected to this patron page
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch fixes the particular use case of the orders route, which has
a slightly modified version of the objects.search helped, embeded in the
controller itself. This controller gets adjusted to the fact q will now
be an array.
Because of the latter, we end up requiring more code duplication
regarding the query fix, so I moved it to an internal sub that gets
reused.
To test:
1. Apply the previous patches
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/*
=> FAIL: It t/db_dependent/api/v1/acquisitions_orders.t fails!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch changes the q_param definition so the defined query parameter
is repeatable. This way JSON::Validator will always generate an arrayref
for it and won't skip occurences.
The objects.search helper is updated to always consider the 'q'
parameter as an array, as expected.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/query.t
=> FAIL: Tests fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When you install a plugin that requires a newer Koha version, it reports
this:
<<
Warning: This report was written for a newer version of Koha. Run at your own risk.
>>
It is wrong in a couple ways:
- It is not a report.
- It feels like it dates back to when plugins were only run i.e.
pre-hooks, etc.
This patch proposes a change to reflect this.
To test:
1. Verify the string changes make sense to you
2. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds the ACCTDETAILS notice trigger to the opac self
registration process. Allowing new users, with varification enabled,
to receive the ACCTDETAILS notice immediately after their account is
varified.
Test plan
1) Enable AutoEmailOpacUser system preference
2) Ensure the ACCTDETAILS notice is configured
3) Ensure `PatronSelfRegistrationVerifyByEmail` is enabled
4) Register a new user via the opac self registration process using an
email address you have access to
5) Verify the user by following the link in the verification email you
should have received.
6) The new user should have been created and you should be able to see
the account details notice in their associated notices
7) Confirm that the email address used above has received the notice.
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch adds the ACCTDETAILS notice trigger to the opac self
registration process. Allowing new users, without varification enabled,
to receive the ACCTDETAILS notice immediately after their account is
created.
Test plan
1) Enable AutoEmailOpacUser system preference
2) Ensure the ACCTDETAILS notice is configured
3) Ensure `PatronSelfRegistrationVerifyByEmail` is disabled
4) Register a new user via the opac self registration process using an
email address you have access to
5) The new user should have been created and you should be able to see
the account details notice in their associated notices
6) Confirm that the email address used above has received the notice.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We removed a bit too much from the skeliton here ;)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
We should not give libraries the ability to compromise patron accounts,
it is considered a huge security issue and nobody in network security
would never recommend allowing passwords to be transmitted in clear text
over email.
It should simply not be possible to send a patron's password in plain text
via email. As such, we should remove this ability from Koha.
Test Plan:
1) Apply this patch
2) Create a patron to generate the ACCTDETAILS email
3) Note you can no longer transmit the patron's password in the email
Signed-off-by: Amit Gupta <amitddng135@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
1 - Define default messaging preferences for a patron category
2 - Go into an existing account and change the patron category to the
one set in step 1.
3 - Confirm that the messaging prefs have been reset to that of the
default patron category
4 - Apply patch
5 - Repeat Step 2, this time you should see a warning asking if you want
to set messaging prefs to the category default
6 - Press OK and save. Confirm that the messaging prefs are now set to
the default for that category
7 - Try it again with an existing account and press Cancel this time.
Notice that there should be no change to the patron messaging prefs.
8 - Try making a new patron and switching the category, you should see
no warning and the message prefs should be proberly set to the
defaults of any category you choose.
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>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>