Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
This is quite a misleading call.
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: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
Run Auth.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: 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: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
It may be that we need a few additional flushes.
And checking the returned session before clearing busc.
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: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If we look for an existing session, do not create a new one.
Found a bug in the unset_userenv calls. For this moment
changing the calls in Auth here. Later fix goes to bug
29954.
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: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When a user is not logged in, a new session ID is generated every time a
new page is hit.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
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>
This patch updates t::lib::Koha::BackgroundJob::BatchTest to the new
style, and also removes a couple stray cases in which job_id was still
passed as a parameter.
Tests are rewritten a bit, so they actually test more of the behaviors.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/BackgroundJobs.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Now $self is actually an instance of the job class, there's no need to
have the job_id parameter passed, or the have the ->process method
re-fetch the object from the database.
This patch cleans things up.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes _derived_class rely on _new_from_dbic to generate a new
object with the right class, but based on the same DB row. Not an empty
one as it was before. This way we can remove some biolerplate that is
required now when writing background job classes.
To test:
1. Apply the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/BackgroundJob.t
=> FAIL: Boo, 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: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch does what the title says. Instead of converting dates to
strings and performing math manually, we can just use the DateTime
objects we have and calculate the DateTime::Duration there's between
them, to get the years count.
To test:
1. Run:
$ kshell
k$ prove t/db_dependent/Koha/Patrons.t
=> SUCCESS: Tests pass
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: 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 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>
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>
This method will allow to filter a patron set by a given subpermission.
It will be useful on bug 30055 where we want to display only patron
with suggestion or acquisition subpermission.
Note that it could be extended to allow several subpermissions, but we
don't need it so far.
Test plan:
prove t/db_dependent/Koha/Patrons.t
must return green
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.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>
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>
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>
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>
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>
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>
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>
This patch makes select2 available for ILL backend developers to use on
their templates.
To test:
1. Have a configured backed and an ILL request
2. Open the inspector and load any action on the backend (intranet)
=> FAIL: no select2 asset is transfered from Koha to the browser
3. Apply this patch
4. Reload
=> SUCCESS: There's select2
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: Fridolin Somers <fridolin.somers@biblibre.com>
This makes two changes:
1 - We no longer call get_items_that_can_fill if there are no holds
2 - The subroutine will return an empty Koha::Items object if there are no holds passed
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: David Nind <david@davidnind.com>
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>
To reproduce (paycollect.pl):
1) Prepare or use some existing patron with outstanding fines, go to
the accounting section and open page where you make payment towards all
fines.
2) The error message should have appeared in your log file about
"File not found : default/js/locale_data.js".
3) Apply the patch.
4) Open the edit page again, ensure that the new error massage like
that didn't appear.
Signed-off-by: David Nind <david@davidnind.com>
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>
To reproduce (memberentry.pl):
1) Head over to the patron details page, press edit button to open the
memberentry.pl page.
2) The error message should have appeared in your log file about
"File not found : default/js/locale_data.js".
3) Apply the patch.
4) Open the edit page again, ensure that the new error massage like
that didn't appear.
Signed-off-by: David Nind <david@davidnind.com>
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>
This patch updates the OPAC suggestions form to update the variable
used to pre-select the logged-in user's library.
To test, apply the patch and make sure the "suggestion" preference is
set to "Allow."
- Log in to the OPAC and click "your purchase suggestions" in the
sidebar menu on your summary page.
- Click "New purchase suggestion."
- The selected library should match the logged-in user's home library.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
I change the magnigying glass icon to FA icon in the staff detail view
for 1xx and 7xx of the record that links to the authority records.
The following test plan is for 100 tag only but the patch can be apply
for all 1xx and 7xx tags that can be connect with an authority record.
Test Plan:
1) On the Koha staff page, create a new authority. The type of authority
will be: e.g Personal Name
2) When creating authority, in tab 1 under -HEADING--PERSONAL NAME enter
the personal name term entry element and then save the
new authority e.g. Twain, Mark.
3) In circulation, search the catalog for a random book. Click the title
of the book and you will be taken to the book details.
4) Edit the record and in tab 1 , scroll down the - MAIN ENTRY--
PERSONAL NAME and repeat this tag (the icon next to the title).
5) Edit the Personal name term entry element by clicking
the button on the right of the bar.
6) In the Search main heading ($a only) enter your personal name term
e.g. Twain, Mark.
7) Press search, and then in the table that pops up, click 'choose'.
8) Save your edits and the new personal name term will be in the 'By:'
of the book details.
9) Notice that there is no magnifying glass icon.
10) Apply this patch
11) Notice that there is now a magnifying glass icon next to the
personal name term.
12) Click on the magnifying glass and it will take you directly to the
authorities records
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>
I added a magnigying glass icon in the staff detail view for 1xx and 7xx
of the record that links to the authority records.
The following test plan is for 100 tag only but the patch can be apply
for all 1xx and 7xx tags that can be connect with an authority record.
Test Plan:
1) On the Koha staff page, create a new authority. The type of authority
will be: e.g Personal Name
2) When creating authority, in tab 1 under -HEADING--PERSONAL NAME enter
the personal name term entry element and then save the
new authority e.g. Twain, Mark.
3) In circulation, search the catalog for a random book. Click the title
of the book and you will be taken to the book details.
4) Edit the record and in tab 1 , scroll down the - MAIN ENTRY--
PERSONAL NAME and repeat this tag (the icon next to the title).
5) Edit the Personal name term entry element by clicking
the button on the right of the bar.
6) In the Search main heading ($a only) enter your personal name term
e.g. Twain, Mark.
7) Press search, and then in the table that pops up, click 'choose'.
8) Save your edits and the new personal name term will be in the 'By:'
of the book details.
9) Notice that there is no magnifying glass icon.
10) Apply this patch
11) Notice that there is now a magnifying glass icon next to the
personal name term.
12) Click on the magnifying glass and it will take you directly to the
authorities records
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>
This patch adds a check for both mandatory and important fields when
validating bibliographic records during cataloguing.
To test:
1. Go to Admin -> Biblio frameworks. View the MARC structure of your
default framework.
2. Search for tag 082. Edit the subfields for this tag.
3. Check the 'important' checkbox for subfield a and Save.
4. Go to add or edit a new biblio record under Cataloguing.
5. Ensure the 082$a field is empty and hit Save.
6. Notice the confirmation pop-up is an unreadable display of HTML.
7. Click Cancel on the pop-up box.
8. Apply the patch and refresh the editor page.
9. Ensure the 082$a field is empty and hit Save.
10. Notice the confirmation pop-up is more helpful this time. Click
Cancel on the pop-up box.
11. Notice the 082$a field is displayed at the top of the page as an
important field that is missing information. Use the 'go to field'
link and confirm this works as expected.
12. Leave 082$a empty and hit Save.
13. This time click OK on the confirmation pop-up. Confirm you are able
to save your record as normal.
Sponsored-by: Education Services Australia SCIS
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>
to test...
1/ set git repo
$ git reset --hard v21.11.03
2/ run test
$ prove ./t
OK
3/ apply patch
4/ run test again, observe FAIL
$ prove ./t/00-check-atomic-updates.pl
./t/00-check-atomic-updates.pl .. 1/?
# Failed test 'check for unhandled atomic updates: bug_29596.pl'
# at ./t/00-check-atomic-updates.pl line 34.
# 'bug_29596.pl'
# matches '(?^u:.*pl$)'
# Looks like you failed 1 test of 3.
./t/00-check-atomic-updates.pl .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests
JD Amended patch: fix copyright year
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
To recrate:
Logout
Go to /cgi-bin/koha/opac-search.pl
Click "Log in to your account"
Fill in the login form
Submit
Check the 'form_serialized' cookie's value
=> Without this patch it contain login/password
=> With this patch applied the cookie is not created
Confirm that the "Return to the last advanced search" feature still
works as expected.
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>
