To test, with this patchset applied:
1) From patron accounting page -> Add a manual invoice
2) Under the transaction tab click 'Cancel charge'
3) You should see a modal that gives you the option to type in a note.
4) Type something in and select submit.
5) Ensure the note shows up in the note column.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Apply patch, restart_all
2) From patron accounting page -> Create manual invoice. Enter some amount and select save and pay. Press confirm.
3) In the transactions tab, for the invoice you just created, under the actions column select issue refund.
4) This should open a modal with the ability to enter a note for the refund. Type in a note and confirm.
5) Ensure the note correctly shows in the table.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) From patron accounting page -> Create manual credit. Put in some amount and press add credit.
2) Under the actions column, select "Void"
3) Notice no option for a note. Press cancel
4) Apply patch, restart_all
5) Press void again. This time, you should see a modal that gives you the option to type in a note.
6) Type something in and select submit.
7) Ensure the note shows up in the note column.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Apply patch, restart_all
2) From patron accounting page -> Create manual credit. Put in some amount and press add credit.
3) Under the actions column, select 'Issue Payout'
4) You can now enter a note. Type something in and press confirm.
5) Ensure the note shows up in the note column.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATCH and restart_all
2. Apply a manual invoice to a patron account.
3. Go to the patron record -> accounting -> transaction tab
4. Look for the 'Apply discount' button.
5. When the 'Apply discount' modal appears notcie the 'Note' field.
6. Add a note, make sure it gets applied to this accountline.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Log non-repeatable attributes and only log changes and creations, not deletions.
When changed, attributes are first all deleted, then the relevant ones are recreated.
This patch catches all deletions, and checks against them in the creation phase, logging
only the attributes that have changed (with before/after content). This makes it impossible
to log actual deletions.
To test:
1) Ensure tests in t/db_dependent/Koha/Patron/Attribute.t passes
Sponsored-by: Gothenburg University Library
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Clemens Tubach <clemens.tubach@kit.edu>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Combining opac with pref template is wrong. This pref should
actually be renamed to something like intranetTheme(s) or so.
Replacing the obsolete prog theme in Languages.t by undef. This
achieves the same: getting all themes for that interface.
Test plan:
Add some languages for opac and intranet. Do not enable exactly
the same set.
Enable TranslateNotices.
Verify that you have all OPAC languages on memberentry and
opac-messaging. And all languages on additional contents.
Run t/db_dependent/Languages.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested with:
OPAC languages: en, nl-NL, de-DE
Staff languages: en, de-DE, fr-FR
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When editing a child while Childneedsquarantor active, trying to delete
a guarantor while saving a non-patron guarantor will prevent the user
from saving. However, if an adult has expired, some librarian would like
to remove the account and let some information in non-patron guarantor.
TEST PLAN
Before applying patch
1 - Open Lisa Charles'page, add Henry Acevedo as Guarantor, also fill
Guarantor surname and firstname
2 - Edit the page and try and remove Henry Acevedo, it won't work
however there is still one guarantor
3 - Apply patch
4 - Try and remove Henry Acevedo -> it will work
5 - add HA as a guarantor again
6 - try and remove him AND let guarantor firstname and surname empty ->
you can't
7 - Add HA and Edna Acosta as guarantor
8 - Remove HA and ler guarantor firstname and surname empty -> you can
Signed-off-by: Thibault Keromnes <thibault.keromnes@univ-paris8.fr>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates sidebar menu markup so that it's consistent, with a
common class (".sidebar_menu") and a unique ID. The style is tied to the
class rather than the ID, simplifying the CSS.
Note: This patch contains indentation changes so ignore whitespace when
viewing the diff.
The updated patch contains corrections to JavaScript which needed
selectors to be changed to match the new markup.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client)
Check pages which contain each modified menu:
- Circulation -> Check out to a patron
- Catalog -> View a bibliographic record
- Administration -> View system preferences
- Acquisitions -> Acquisitions home
- Cataloging -> Stock rotation -> Manage stages and manage items for a
rotation
- Cataloging -> Stage MARC records for import
- Reports -> Acquisitions statistics
- Reports -> View dictionary
- Point of sale
- E-resource management
- Preservation
- Serials
- Tools -> Patron lists
Sponsored-by: Athens County Public Libraries
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This fixes an internal server error when renewing an expired
child patron without a guarantor, when the ChildNeedsGuarantor
is set to "must have".
Test plan:
1. Create or edit a child patron:
- Don't add a guarantor.
- Set the "Expiry date" to a date in the past.
2. Set the ChildNeedsGuarantor system preference to "must have".
3. Refresh or view the patron's check out or details page, and
select the "Renew" link under the attention heading -
this generates an internal server error message.
4. Apply patch.
5. Repeat step 3, you will now get a standard error message
"This patron could not be renewed: they need a guarantor."
6. Add a guarantor for the patron.
7. Repeat step 3, and click "Renew" - the patron is now renewed.
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>
When we attempt to add child as guarantor the error message shown is 'A guarantor cannot be a guarantee.' it doesn't make sense
To recreate:
1. Go to Patrons
2. Click 'New patron' > 'Kid'
3. Fill out surname and cardnumber
4. Under Patron guarantor, click Add guarantor
5. Search for category = Kid and choose one of the patrons
6. Choose the relationship
7. Click 'Save'
--> Error A guarantor cannot be a guarantee.
8. Apply the patch
9. repeat previous steps
10. After clicking Save
--> the error message shown is «Child patron cannot be a guarantor.»
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>
This commit is generated using:
% perl misc/devel/tidy.pl
*within* ktd, to get the same version of perltidy than what will be used
by our CI (currently v20230309).
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
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>
