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>
git grep members/search.pl
should not return any results
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Use of uninitialized value $op in string eq at /kohadevbox/koha/members/memberentry.pl line 86.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch converts the delivery delete buttons to a form and changes
the corresponding op check in the script.
The patch also fixes an error in the form markup and corrects the op
parameter name in several links.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I also move the writeoff handling out of it's own block in into the rest
of the x_individual handling.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The pay to paycollect post/redirect flow here doesn't actually
consistute a state change, however it's much simpler to add the csrf
token check flow here than to refactor the code to a get (url's quickly
grow too large for a GET) or rework it in other ways. I opted to do
this for now and work on a refactor at a future date.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 34478: TO SQUASH op modify=>edit_form, add=>add_form ( pass opadd to template )- memberentry.pl
The template expects opadd when showing the form - along the way it was changed to 'add' and broke new patron
entry
Bug 34478: TO SQUASH op modify=>edit_form, add=>add_form ( pass op to template )- memberentry.pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 34478: [TO SQUASH] actionType parameter not used - memberentry.pl
syntax error at members/memberentry.pl line 103, near "\|"
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
