This patch adds a new field 'preferred_name' to the patron record.
On storage (creation or update) the preferred_name is set to the firstname if no
value is passed. Patron modifications will set the preferred name to the firstname if
the preferred_name field is hidden
With this patchset preferred_name will always be set - either to the firstname, or a specified value.
PatronAutoComplete/ysearch is updated to use 'preferred_name'
To test:
1 - Apply patches
2 - Update database and restart all, clear browser cache
3 - Load a patron in staff module
4 - Confirm you see and can add a preferred name
5 - Confirm the preferred name and first name now displays on patron details
6 - Remove first name from patron record and confirm it no longer shows
7 - Edit sysprefs BorrowerMandatoryFields and BorrowerUnwantedFields to confirm you can make
new field required or hidden
8 - Sign in as patron to opac
9 - Confirm preferred name shows
10 - Edit account on opac and confirm field is present
11 - Verify DefaultPatronSearchFields contains 'preferredname' if your pref had firstname
12 - Perform checkout and patron search using preferred_name, confirm patron is found
13 - Enable PatronAutoComplete system preference
14 - Type patron's surname into Checkout or patron search but don't hit enter
15 - Confirm patron is displayed with 'preferred_name' in the preview
16 - Set 'preferred_name' in all 'Unwanted' preferences
17 - Confirm editing a patron in staff interface sets both fields when firstname updated
18 - Confirm a patron modification sets both fields when firstname updated
19 - Create a patron / perform self registration and confirm both fields set when preferred_name is hidden
20 - Remove preferred_name from Unwanted prefs and confirm preferred_name is set to firstname if nothing passed
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Add a return; in AddFile to simulate a failing db insert.
Verify that an alert pops up.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Currently, if you have patron attributes and modify the values in a patron's account, the patron's updated_on date is not updated. This patch makes the "Updated on" change when a patron attribute is updated.
To test:
1. Create a patron attribute type
1.1. Go to Administration > Patron attribute types
1.2. Click New patron attribute
1.3. Fill out the code and description
1.4. Click Save
2. Edit a patron (normal)
2.1. Go to Patrons and find a patron account
2.2. Click Edit
2.3. Change a regular field (e.g. Middle name)
2.4. Click Save
--> Notice the "Updated on" date in the left column has been updated to now
3. Edit a patron attribute
3.1. In another patron account*, click Edit
3.2. Change the value of an attribute
3.3. Click Save
--> Notice the "Updated on" date did not change
4. Apply the patch
4.1 Repeat step 3.1, 3.2, 3.3
--> Notice the "Updated on" date has now changed
Signed-off-by: Esther <esther@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
members/cancel-charge.pl will take either a POST or a GET, and as long as the
accountline_id it is passed can be cancelled, will cancel it. That means any
link you click anywhere while logged in to Koha might cancel a charge. It also
takes a borrowernumber which isn't used for the cancelling, only to determine
what account to show after a charge is cancelled, letting a malicious link
show an account other than the one whose charge was just cancelled.
Test plan:
1. Without the patch, Circulation - Checkout - search for the 'koha' patron
you log in as
2. Accounting - Create manual invoice - Make it a Manual fee of 100.00 and
Save
3. Pretending it's a well-disguised link in a spear-phishing email, load
http://localhost:8081/cgi-bin/koha/members/cancel-charge.pl?borrowernumber=5&accountlines_id=1
4. You are now looking at charges for the patron Acosta, Edna rather than for
the patron koha, but if you look at the patron koha, its 100.00 charge
has been cancelled.
5. Apply patch and reset_all (or if you don't, you'll have to manually adjust
the link to reflect the charge being accountlines_id 3 rather than 1)
6. Circulation - Checkout - search for the 'koha' patron you log in as
7. Accounting - Create manual invoice - Make it a Manual fee of 100.00 and
Save
8. Click the link http://localhost:8081/cgi-bin/koha/members/cancel-charge.pl?borrowernumber=5&accountlines_id=1
9. You got a 403 because you didn't pass the op cud-cancel, but if you did
pass that op, you would also get a 403 for having a cud- op in a GET (and
if you POST, you won't have a csrf_token)
10. Checkout - search for koha - Accounting - Cancel charge
11. Having done it the right way, you're now on koha's list of transactions,
where you can see you just cancelled it
Sponsored-by: Chetco Community Public Library
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Patron may be undefined. So the test may crash.
Also there is an issue with operator precedence.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
[SQUASHED IN QA]
These patches will alter the checks for a patron that prevent a category with
'can_be_guarantee' from being a guarantor. Two patrons in the same category should be
allowed to have a guarantee/guarantor relationship
The tests below assume you are using the KTD sample data. Update borrowernumbers if not.
To test:
0 - Apply tests patch
1 - Set the 'Patron' category as 'Can be a guarantee'
2 - Add a relationship between two patrons of the same category
This is restricted from the staff interface
perl -e 'use Koha::Patrons; my $p = Koha::Patrons->find(5)->add_guarantor({ guarantor_id => 23, relationship => 'father'});'
3 - Note there is no warning or exception. This should be allowed.
4 - Checkout an item to Edna (borrowernumber 5)
5 - Set 'TrackLastPatronActivityTriggers' to 'Checking in an item'
6 - Try to check the item in, KABOOM
7 - Set 'TrackLastPatronActivityTriggers' to 'Checking out an item'
8 - Try to issue an item to Enda, KABOOM
9 - prove -v t/db_dependent/Koha/Patron.t, fail
10 - Apply second patch
11 - prove -v t/db_dependent/Koha/Patron.t, one more test passes, but then fail
12 - Apply third patch
13 - prove -v t/db_dependent/Koha/Patron.t, pass!
14 - restart_all
15 - Checkout to Enda, OK!
16 - Checkin from Edna, OK!
17 - Find two more patrons in the category and attempt to link them
18 - 'Guarantor cannot be a guarantee'
19 - Apply fourth patch
20 - You can add a guarantor from the same category in interface
21 - Try to add a guarantor to the guarantor assigned in 20
22 - Confirm you cannot add a guarantor - "Guarantor cannot be a guarantee"
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: Fix patron updates
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: Fix patron creation
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: Fix memberentry.pl
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: (follow-up) Fix patron creation
This patch fixes the 22. of the test plan (22 - Confirm you cannot add a guarantor - "Guarantor cannot be a guarantee"
)
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Bug 37892: (follow-up) Fix patron creation
TEST PLAN:
1 - Do the 22 parts of the test plan
2 - Add a guarantor to one patron not selected before (let's say A is
the guarantee, B the guarantor)
3 - Try and add a guarantor to B -> you will success
4 - Remove B's guarantor
5 - Apply this patch
6 - Repeat 3 -> you will not be able to
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Bug 37892: (follow-up) Tidyness
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT]
Renamed a subtest to patron creation tests in Patron.t.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch checks if the selected relationship is valid before trying to save the patron record.
It takes the list of valid relationships from borrowerRelationships syspref and checks if the selected relationship is in the list.
Also this patch fixes relationship field required message when BorrowerMandatoryField is not set.
The required message is shown when adding the guarantee from guarantor's detail page.
Test plan:
1) Add at least one option to borrowerRelationships syspref.
2) Leave the relationship unchecked from BorrowerMandatoryField syspref.
3) Create a new guarantee patron.
4) Add a guarantor to the guarantee patron.
5) Leave the relationship field empty and try to save the patron record.
6) Notice the 500 error page.
7) Apply the patch.
8) Repeat steps 3-5.
9) Notice the error message "Guarantor relationship is invalid".
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The original submission missed a number of slip types that are print on
demand without queueing.
These all need an "id" passing in to the template and in some cases we
were also missing passing in the new style parameter too (preservation)
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When moving the style up, it was moved before the code that handles printing a single slip, i.e.
taking the variables and forming a slip hash.
This patch moves that code to the top and additionally passes through the CODE of the notice so the ID is not blank
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch fixes issue introduced by BZ32530
Test Plan (on main):
1 - Edit a patron
2 - Do not change anything and submit -> you get an error
3 - Apply both patches
4 - Repeat 1&2 -> everything works fine
5 - Try and delete the guarantor -> it will be deleted
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
A drive-by patch which hopes to resolve bug 36085 by only allowing superlibrarians
to protect or unprotect patrons.
Test plan:
a) prepare two koha staff users:
1) a superlibrarian
2) a user that only has permission to edit patrons
b) when logged in as the user prepared in step a2 (non-superlibrarian),
then go to edit any patron
*) note how you can set the protected yes/no radios
c) apply the patch
d) repeat steps a-b as this same user
*) note how you can now no longer see the protected yes/no radios
e) log in as the user prepared in step a1 (superlibrarian), then repeat
steps a-b
f) note how the protected yes/no radios are back
Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan, k-t-d:
Preparation: Create additional fields for table 'accountlines:credit',
visit:
/cgi-bin/koha/admin/additional-fields.pl?tablename=accountlines%3Acredit
2 text fields, one repeatable, one not-repeatable
2 AV fields, one repeatable, one not-repeatable
1) Add a new manual credit for admin borrower:
/cgi-bin/koha/members/mancredit.pl?borrowernumber=51
2) Set the mandatory "Amount" input (e.g. '5'). Click the 'Next' and
press 'Ok' on the alert box.
3) Fill in all additional fields, click the '+New' and 'Clear' links,
hit 'Save'
4) On the table, click "Details" for the for account line we just
created.
5) Notice the additional fields are there, repeated fields are comma
separated.
6) Repeat the above test plan, but for accountlines:debit instead,
visit:
/cgi-bin/koha/admin/additional-fields.pl?tablename=accountlines%3Adebit
7) To add a manual invoice, visit:
/cgi-bin/koha/members/maninvoice.pl?borrowernumber=51
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch passes the suspected duplicate to the template and uses patron title to display very brief info.
If the user cannot view the patron there is no longer a link tot he brief popup and they will only see
'A patron from library X"
There is a FIXME asking if we should use search_limited - I believe we should check all branches, so the staff can ask the patron if they
have an exising account in a consortium depending on rules about multiple cards
To test:
1 - Edit a user to grant catalogue and all borrower permissions except 'view_borrower_infos_from_any_libraries'
2 - Find a patron from a different library and note surname and firstname
3 - Login as the patron above
4 - Enter a new patron with the same surname and firstname
5 - See the 'Duplicate patron' warning
6 - Click to view the patron
7 - No info is listed
8 - Apply patch
9 - Reload and resubmit - or fill out form again
10 - Note that you see 'A patron from library XXX' and no popup link
11 - Add view_borrower_infos_from_any_libraries to the staff
12 - Repeat the duplication and confirm the warning now has patron name and the popup link is visible and works
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates all instances where the current noissuescharge sysprefs are used. They will now use the is_patron_inside_charge_limits method to handle the patron category level limits
Sponsored-by: Cuyahoga County Public Library <https://cuyahogalibrary.org/>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There are a number of libraries that would like for their staff to be able to submit (and view existing) purchase suggestions from the borrower record, but not give the staff the ability to edit/manage/delete purchase suggestions.
Test Plan:
1) Apply this patch
2) Run restart all the things!
3) Run updatedatabase
4) Verify anyone with the suggestions manage permissions now has the create and delete permissions as well
5) Verify anyone without the suggestions manage permission has not recieved the new permissions
6) Enable only the create permission for a librarian
7) Verify that librarian can only create new suggestions ( not manage or delete )
8) Enable only the manage permission for a librarian
9) Verify that librarian can only manage existing suggestions ( not create or delete )
10) Enable only the delete permission for a librarian
11) Verify that librarian can only delete suggestions ( not create or manage )
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Sponsored-by: Cuyahoga County Public Library
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
APPLY PATCH and restart_all
1. Have a patron with and some holds and different priority.
2. Go to the patron account and click Print > Print summary
3. Notice the new holds priority column.
Note: Table settings don't work on these tables. See Bug 36475.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
While adding new patron, if patron is flagged as duplicate
or another error occurs and their home library differs from
library user is logged in, patrons home library resets as
logged in users library. This happens with all patrons
expect those with category type C. This patch removes checking
if patrons category type is C from code so that all category
types use previously chosen home library even if error occurs.
To test:
1. Add new patron and set their library to a different
library than the one you're logged in.
2. Cause an error (wrong age, duplicate etc) while saving.
3. Attempt to save.
=> Note that patrons home library is set as one you're
logged in.
4. Apply this patch.
5. Repeat steps 1 to 3.
=> Note that patrons home library hasn't changed.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Esther <esther@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This makes the necessary changes in the patron module of
the staff interface, so the new patron attribute appers and
behaves correctly when editing a patron record.
To test:
* You will need to test different configuration options for
extended patron attributes (PA) in combination with the date option:
* PA is a date and not mandatory
* Patron form should have the calendar widget to let you set the date.
* PA is a date and mandatory
* Patron form shoudl have calendar widget and check that the date is
set for allowing you to save the record.
* PA is a date and unique
* For this set the date in one patron record and try to
set the same date in another. You should not be able to save.
* PA displays in brief patron information
* Make sure the date displays on the left formatted correctly
* When the date PAs are saved, they should display nicely formatted
on the details tab.
Signed-off-by: Philip Orr <philip.orr@lmscloud.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Go to a patron accounting page
2. Create a manual invoice and Save
3. Click the Print button in the patron toolbar
4. Click the 'Print account balance' button
5. Confirm your format settings for ACCOUNTS_SUMMARY are applied
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Go to a patron accounting page
2. Create a manual invoice and Save
3. You'll be redirected to the Transactions tab
4. Click the Pay button next to your invoice and confirm Payment
5. Click the Print button next to your Payment
6. Confirm your format settings for ACCOUNT_CREDIT are applied
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Go to a patron accounting page
2. Create a manual invoice and Save
3. You'll be redirected to the Transactions tab
4. Click the Print button next to your invoice
5. Confirm your format settings for ACCOUNT_DEBIT are applied
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Check out an item to a user. Set the due date to a time in the past so it is overdue
2. Click Print in the members toolbar, then Print overdues
3. Confirm your format settings for OVERDUES_SLIP are applied
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Check out an item to a patron
2. Click Print in the members toolbar, then Print quick slip
3. Confirm your format settings for ISSUEQSLIP are applied
4. Click Print in the members toolbar, then Print slip
5. Confirm your format settings for ISSUESLIP are applied
6. Return the item
7. When the item is checked in, click the 'Print checkin slip' button
8. Confirm your format settings for CHECKINSLIP are applied
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Koha/Illrequests.pm -> Koha/ILL/Requests.pm
Merged:
t/db_dependent/Koha/Illrequests.t
t/db_dependent/Illrequests.t
Into:
t/db_dependent/Koha/ILL/Requests.t
ILL classes file structure is, for the most part, around 7 years old and doesn't follow a strict logic. It's so confusing that some test files exist redundantly.
This housekeeping should help future work in regards to ISO18626 to add Koha as a supplying agency instead of just requesting agency, as is now.
It should also help future housekeeping of moving backend related logic out of the Illrequest.pm into Illbackend.pm (now ILL/Request.pm and ILL/Backend.pm as of this patchset).
It should also help in structuring the addition of a master generic form (see bug 35570)
This patchset will require existing backends to be updated to match the new class names and structure, if they invoke them.
Test plan, k-t-d, run tests:
prove t/db_dependent/api/v1/ill_*
prove t/db_dependent/Koha/ILL/*
Test plan, k-t-d, manual:
1) Install FreeForm, enable ILL module, run:
bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.sh)
2) You'll have to switch the FreeForm repo to the one compatible with this work, like:
cd /kohadevbox/koha/Koha/Illbackends/FreeForm
git checkout reorganize_ILL
3) Do some generic ILL testing:
3.1) Create a request
3.2) Add a comment to a request
3.3) Edit a request
3.4) Edit a request's item metadata
3.5) Confirm a request
3.6) List requests
3.7) Filter requests list using left side filters
4) Install a metadata enrichment plugin:
https://github.com/PTFS-Europe/koha-plugin-api-pubmed
4.1) Create an ILL batch and insert a pubmedid like 123
4.2) Add the request and finish batch
5) Verify all of the above works as expected
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATACH and restart services.
2. Find the borrowerRelationship system preference. The description should no longer include the words "Leave empty to deactivate."
3. Populate the system preference with at least 1 choice.
4. Find a patron category with can_be_guarantee set to 'Yes'.
5. Quick add a patron of that type, making sure the relationship field shows in the Patron guarantor section. ( You have to +Add gaurantor before this field will show )
6. The values in the dropdown should refelct the borrowerRelationship values.
7. With BorrowerMandatoryField make relationship mandatory.
8. Try step 5 again, this time the Relationship field should be mandatory.
9. Remove the field from BorrowerMandatoryField and add it to BorrowerUnwantedField.
10. Do step 5 again, the relationship field should not show on the quick add form.
Signed-off-by: Myka Kennedy Stephens <mkstephens@fosgail.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the change password page on the staff interface to
allow for changing the patron's username without changing the password.
If the new password is an empty string we can skip setting the patron's
password and sending the new password to the template.
Test plan:
1. From a patron record tool bar click 'Change password'
2. Notice that if you try to change the user's name without also
changing the password the page just reloads and nothing happens
3. Apply patch and restart_all
4. From the patron record click 'Change password' again
5. Set the user's new username and password eg. '1234Abc' and click
'Save'
6. Confirm that you can log in to the OPAC with the user
7. Return to the patron record and click 'Change password' again
8. This time change just the 'New username field' and click 'Save'
6. Notice that the username is updated
7. Confirm you can log into the OPAC with the new username and the
original password '1234Abcd'
8. Make sure that the change password form still validates passwords
for length and matching errors etc
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Bug 31422 added a warning message when library limitations issue in patron edition page.
We should add this patron's messages in circ and details pages.
Like age limitations.
Test plan:
1) User's login branch and home library is: Centerville
2) Patron category "B - Board" is limited to Franklin
3) Edit a patron with Board category from Centerville
4) A message appears "The patron's current category (Board) is limited to other libraries."
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
As Emmy stated on comment9, this line is indeed unneeded (and wrong).
A successful cud-insert/cud-save does not come here.
And it is set for add_form, edit_form and duplicate later on.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If an error occurs while adding new patron, after fixing the error and
hitting save, patron entry page reloads to "Modify patron" section
and error "Patron not found. Return to search" is displayed. But no
patron is saved.
This happens because we declare template param op too early in the
code and it receives value "cud-insert" instead of "add_form" as it should.
To test:
1. Add new patron and cause an error (wrong age etc.).
2. Attempt to save patron, error message is displayed.
3. Fix your errors and attempt to save again.
=> Error message "Patron not found. Return to search" is displayed and new
patron is not saved to database.
4. Apply this patch.
5. Repeat steps from 1 to 3.
=> Saving patron should now work.
=> To be save, test if modifying patron also works as it should.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We update the 'Send welcome email' button to read 'Send welcome notice'
and add a fallback to enqueue a notice for print when the user doesn't
have an email address defined.
Test plan
1) Apply patch
2) Use the 'Henry Acevedo' user who doesn't yet have a valid email
address.
3) Click the 'Send welcome notice' button available from the 'more'
menu.
4) Note that no notice is queued at all.
5) Copy the content of the 'email' WELCOME notice into the 'print'
template.
5) Repeat step 3.
6) Note that this time a 'print' type notice is queued for the user.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
hen dateexpiry is in BorrowerUnwantedField it is hidden in patron edition form.
The problem is when editing an existing patron the value is re-computed with category settings, as if it where empty.
This comes from all fields in BorrowerUnwantedField beeing removed from %newdata in memberentry.pl.
Whe must skip dateexpiry.
Test plan :
1) Be sure dateexpiry is not in BorrowerUnwantedField
2) Define a patron category with enrollment period 12 month
3) Create a new patron in this category
4) Its expiration date is in now + 12 month
5) Edit the patron category to set enrollment period 6 month
6) Add dateexpiry in BorrowerUnwantedField
7) Edit the patron and save
=> Without patch the expiration date is changed to now + 6 month
=> With patch the exporation date is unchanged
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Perl-tidied.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Same test plan as the other patch, behavior is expected to be the same on both
But this alternative removes technical debt, whereas the other patch adds.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
With the previous patches applied and successfull test plans, access the users ILL history page, visit:
/cgi-bin/koha/members/ill-requests.pl?borrowernumber=51
Notice you get an error.
Apply this patch, and try again, notice the error is gone and the custom plugin action is also in the patron's ILL history table
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch remove the REST API call in select_user function and retrieve the patron's data from borrower_data
To test:
1) Apply patch
2) Search PrefillGuaranteeField preference and make sure some fields are selected
3) Select a user that can have a guarantor
4) In the edit form, click on "Search to add" in "Patron guarantor" fieldset
5) Choose a patron who has at least one of the fields in 1) set
6) Click Select
7) Confirm guarantee's information is filled from the guarantor's record
8) Check that any preexisting information is not overwritten
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This attachment correct the populate of fields by using the api mapping.
Now All fields are populated following the selected PrefillGuaranteeField options
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When creating a new guarantee from the guarantor, the preference PrefillGuaranteeField dictates some fields to be transfered from guarantor to guarantee. This patch makes it so those informations are also transfered when adding a new guarantor relationship to an existing patron.
To test:
1) Apply patch
2) Search PrefillGuaranteeField preference and make sure some fields are selected
3) Select a user that can have a guarantor
4) In the edit form, click on 'Search to add' in 'Patron guarantor' fieldset
5) Choose a patron who has at least one of the fields in 1) set
6) Click 'Select'
7) Confirm guarantee's information is filled from the guarantor's record
8) Check that any preexisting information is not overwritten
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
opac-shelves - forms were stateless - changed to GET
sco-main - forms stateless - changed to GET
** untested because sco + auth is broken
smart-rules.tt - JS form template - added placeholder 'cud-' op
ill-requests - added cud- tp ops
** tested comments, but not checkout, simple changes
boraccount - removed repeated op - updated script
patroncards/edit-batch - add placeholder 'cud-' op
patroncards/manage - add placheholder 'cud-' op
elasticsearch/mappings - separate forms - this could use a style follow-up, but makes more sense separate I think
reports/dictionary - stateless - changed to GET
guided_reports_start - stateless - changed to GET
suggestion/suggestion - add placeholder 'cud-' op
inventory - filed bug 36305, needs more handling
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Remove archived suggestions in patron's account page
Test plan:
1. Go to a patron's account in the staff interface
2. Go to the Suggestions tab
3. Click New purchase suggestion and create a suggestion
4. In another browser tab, go to Acquisitions > Suggestions
5. Click the small arrow next to the edit button to the right of the suggestion, and choose Archive (alternatively, check the suggestion's box and click Archive selected)
--> Suggestion disappears from the suggestions management page (OK)
6. Go back to the tab with the patron's account and refresh
--> Suggestion is still visible
7. Apply the patch
8. Redo step 6 and notice the suggestion is not visible anymore
9. Redo step 4 and 5 but this time, unarchiving the suggestion
10. Redo step 6 and notice the suggestion is back
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Nick Clemens
Marcel de Rooy
Jonathan Druart
Kyle M Hall
Hammat Wele
Phil Ringnalda
Baptiste Wojtkowski
Johanna Räisä
Martin Renvoize
Paul Derscheid
PerplexedTheta
Pedro Amorim
Emily Lamancusa
Matt Blenkinsop
Lucas Gass
Emmi Takkinen
Katrin Fischer
Aleisha Amohia
Brendan Lawlor
Fridolin Somers
Shi Yao Wang