I've updated the test plan since the REST API route takes a little time to respond
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) Wait until save button is enabled
8) Confirm guarantee's information is filled from the guarantor's record
9) 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>
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>
This patch updates the checkouts table so handle 'booked' items
including linking to the biblio booking details page.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Put an item with no holds/recalls in transit (manually or by checking
it in at a branch other than its homebranch to trigger a ReturnToHome)
2. Go to the item's bib record
--> Note that the item's status will display as something like,
"In transit from X to Y since 01/29/2024 Available"
3. Apply patch and refresh the page
--> Note that item now shows only the transit status, but not "Available"
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
-APPLY PATCH
-Review the OPAC results and staff interface results pages.
-Nothing should change, it would be impossible to end up inside of the [% IF koha_spsuggest %] condition because there is nothing like that in the scripts!
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>
To test:
1. Add a guarantee / guarantor relationship for two patrons.
2. Add a manual fee to the guarantees' account.
3. Go to the guarantor's account and view the 'Details' tab. Under contact information there should be a Guarantees section. There you will see the charges for your guarantee. Click on ‘See all charges’. The link leads you no where.
4. Apply the patch and restart_all
5. Refresh the guarantor’s page and click on ‘See all charges’ again. This time it will take you down to the ‘Guarantees’ Charges’ panel.
6. Sign off and have a great day! :D
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>
In new patrons search via API, the road type code is displayed in patron address instead of authorized value description.
Also road type is missing a space separator in DE and FR format.
Test plan :
1) Create two entries in authorized value category "ROADTYPE" :
R1 "Road"
R2 "Street"
2) Edit a patron (ie Delgado, Floyd) to set road type to "Road"
3) Perform a search on patrons (click on letter D)
4) Check you see in address "Road" and not "R1"
5) Edit authorized value category "ROADTYPE" to delete entry "R1"
6) Perform a search on patrons (click on letter D)
7) Check you see in address "R1"
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>
To test:
1) Set an expiration on the password in a patron account and save.
2) Go to patron details (moremember.pl) and confirm the password has an expiration.
3) Edit the patron account without touching anything and save the account.
4) Go back to patron details (moremember.pl) and note that the expiration on the password has been removed.
5) APPLY PATCH
6) Try 1 - 4 again except this time password expiration is not removed.
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATCH
2. As a logged in OPAC user go to 'Your account' > Purchase suggestion. The form should display.
3. Make a suggestion and confirm it works.
4. Try to make a suggestion using title, author, isbn information from an item that already exists.
5. See the "A similar document already exists:" warning. Confirm the suggestion anyways.
6. Set MaxTotalSuggestions to 4 and NumberOfSuggestionDays to 2. Make sure you can still navigate to the purchase suggestion form.
7. Do an OPAC search that will yield no results as a logged in user.
8. Click the "Make a purchase suggestion" link, making sure it works.
9. Turn on AnonSuggestions and log out of the OPAC.
10. Do an OPAC search that will yield no results. Again click the "Make a purchase suggestion", confirm it works.
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>
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>
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>
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>
We need a new method filter_by_future in Koha::Bookings.
Additionally this TT plugin's method was not covered by tests. Neither
is the whole Koha::Booking[s] objects btw.
Test plan:
Confirm that the number of bookings is displayed in the "Bookings" tab
in the left menu of the bibliographic record detail page.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We can replace it with biblio.items.filter_by_bookable, no need to have this TT method.
Additionally there was no test for it.
Test plan:
Make sure the Bookings tab on the left of the biblio detail page is
displayed when needed.
Note that there is also a "Place booking" button that should appear in
the toolbar.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The "biblio" Koha::Biblio object we send from the controller needs to be
accessible from the include files.
To avoid a clash we rename it biblio_info
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We can use biblio.holds.count instead.
The main idea here is to make sure we are passing a Koha::Biblio object
as 'biblio' to all the templates including biblio-view-menu.inc
Test plan:
1. Go to the biblio detail view, click on the different entries in the menu
on the left. Confirm that the "Holds" tab always has the correct number
of Holds display in the parenthesis.
2. Run a search and confirm that the number of holds are still displayed
for each result.
QA:
git grep biblio-view-menu.inc
notice the tt list, open the corresponding perl controllers and confirm
that 'biblio' is passed and that it is a Koha::Biblio object.
The only missing place I found was in viewlog.
Note that we are not removing the TT method yet, we are marking it as
deprecated and also display a warning during the update DB process in
case one of the notice templates is using it.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch moves the dropdown to use select2 and avoids loading all
vendors at page load.
To test:
1 - Create some extra vendors in your system, ideally over 20
2 - Search for a vendor in acquisitions
3 - Click 'Invoices'
4 - Note the dropdown of all vendors 'Vendor:' in search bar on left
5 - The vendor you came from shoudl eb selected
6 - Apply patch
7 - Repeat
8 - Note only a partial list of vendors is loaded, confirm current vendor still selected
9 - Search in the dropdown and confirm vendors are returned
10 - Select a vendor and search
11 - confirm selection is retained
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Rebased-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan, ktd:
- Add 'FreeForm' backend and enable ILLModule, run:
bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.sh)
- Install a metadata enrichment plugin, e.g.:
https://github.com/PTFS-Europe/koha-plugin-api-pubmed/releases
- Add 21 batches, run the following command in kshell:
for x in {1..21}; do echo "INSERT INTO illbatches (name, backend, library_id, status_code, patron_id) VALUES ('$x', 'FreeForm', 'CPL', 'NEW', 52);"; done | koha-mysql kohadev
- Visit ILL batches page:
<INTRA_URL>/cgi-bin/koha/ill/ill-requests.pl?method=batch_list
- Notice only 20 batches show.
- Apply patch. Notice 20 batches show but now there is a page 2 link.
- Test page 2 works as expected, delete a batch, notice only 1 page with 20 batches shows again.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Edith Speller <edith.speller@ukhsa.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Most of the patrons searches open in a modal. Except:
* the main one (members-home)
* when placing a hold
* when requesting an article
(did I miss one?)
The patron-search.inc BLOCKs need a parent block to know where to locate
the elements (form, table, etc), because we can have several patron
searches on the same page.
Bug 35329 reused '#searchresults':
10 [% SET search_results_block_id = 'searchresults' %]
which is used on the main patron search.
The ones in the modal are correctly handled: we build the parent node in
the "patron_search_modal" block.
But for the 2 others the parent block id is wrong.
On reserve/request.tt we have one already, so we set the TT variable from the
.tt file
On circ/request-article we don't have one already, so we can reuse
searchresults (could be more specific however to include 'patrons'...)
Test plan:
Browse patrons by first letter when placing a hold and requesting an
article
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This removes the paging from the bookings request so we take into
account all bookings.
We may want to replace this with date bounded paging in the future, but
lets not try to optimise until we need to.
To test:
1 - Find a record detail page in Koha staff interface
2 - Click on a barcode to go to items tab
3 - Edit 'bookable' to 'yes'
4 - Return to details page
5 - Place 5 bookings on a record
6 - Set system preference RESTDefaultPageSize 2
7 - Click the 'Bookings' tab on the record details
8 - Confirm onyl 2 bookings shown in calendar view
9 - Apply patch, reload
10 - All bookings now show in calendar
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Add some data to a freetext system preference like IntranetUserJS or AdditionalFieldsInZ3950ResultAuthSearch that includes a semicolon;
2. Save the pref and reload the page or check the DB. Everything after the semicolon is removed.
3. Apply patch, try again. Data should remain as is.
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
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>
When changing action links into forms, we should use a submit button rather than JS to submit
Receipt cancelling needed a form embedded in the page as we cannot nest forms
Fixed searching on invoice.pl
Fixed resetting mappings (original button did not need cud-)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch addresses the CSRF error when receiving in acquisitions.
To test:
1. Have at least one order to receive
2. Follow the steps to receive them
3. Have the logs open:
$ ktd --shell
k$ tail -f /var/log/koha/kohadev/*.log
4. Click to confirm receipt
=> FAIL: An error modal is displayed
=> FAIL: There's an error about missing CSRF token in POST
5. Apply this patch
6. Reload everything:
k$ restart_all
7. Repeat 1-4
=> SUCCESS: Receipt works :-D
=> SUCCESS: No error log
8. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We retrieve a list of records for DT, it does not need to be a POST
request.
Test plan:
1. Try an item search
2. The page loads but pops an alert that says "403: Forbidden" and table stays empty
3. Apply patch
4. Try an item search again and the table loads results
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We retrieve a list of records for DT, it does not need to be a POST
request.
Test plan:
1. Stage a batch
2. When it's done, click on "view batch"
=> Without this patch the page loads but pops an alert that says "403: Forbidden" and table stays empty
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
No idea why we are passing issue_escaped instead of the id, but this
patch fixes the regression.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Admin > Circ & fine rules
2. Select a library at the top of the forms ( #selectlibrary )
3. Try to change the 'Refund lost item replacement fee' to "Refund lost item charge (only if unpaid)".
4. Press save and let the page reload.
5. Look at the dropdown again, the value is now set to "Refund lost item charge and restore overdue fine".
6. APPLY PATCH
7. Try steps 2 - 5 again but this time the value in the dropdown should not change.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This link is broken and doesn't make sense from a UI/UX perspective
and thus should be removed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Add some JS like this to any of the UserJS system preferences:
$(document).ready( function() {
let something = 1;
const another_thing = 2;
let an_arrow_function = (a, b) => a + b;
console.log( an_arrow_function(something, another_thing) );
});
2. Notice the icons and warnings to the left of the line numbers:
let is available in ES6
const is available in ES6
arrow_function_syntax is available in ES6
3. APPLY PATCH
4. Try steps 1 and 2 again, the warnings should be gone.
5. Check that the JavaScript still works, in my example it should console.log 3.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Turn on the syspref 'OpacCatalogConcerns'
2. Go to view a record in the OPAC and click on "Report a concern" in
the column located on the right-hand side.
3. Fill out the title on the form and leave everything else the same.
Click on submit and notice that the message on the screen says "Your
concern was sucessfully submitted."
4. Apply the patch.
5. Submit a new concern. Notice that the text now has "successfully"
spelled correctly.
6. Sign off and have a great day! :D
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Turn on the syspref 'CatalogConcerns'
2. Go to view a record in the staff intranet and click on "New catalog concern" which is located in the "+New" dropdown.
3. Fill out the title on the form and leave everything else the same. Click on submit and notice that the message on the screen says "Your concern was sucessfully submitted."
4. Apply the patch.
5. Refresh the page and submit a new concern. Notice that the message now has "successfully" spelled correctly.
6. Sign off and have a wonderful day! :D
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
1) Enable UseRecalls
2) Checkout an item to a patron:
Top INTRA search bar: pick 'check out' and paste a patron
cardnumber:
23529000035676
press enter
3) Enter an item barcode:
39999000003154
Press checkout
4) As user koha/koha, visit OPAC page for this biblio:
opac-url/cgi-bin/koha/opac-detail.pl?biblionumber=76
5) Notice all sidebar actions on the right have hover effect except for
'Place recall'
Apply patch, repeat test plan.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The "Next" pagination button in the OPAC result list has a double angle
whereas the "Previous" button only has a single angle. This patch fixes
that error.
To test:
1) Do a search in the OPAC with more than one page of results.
2) Observe that the "Next" button has a double angle whereas the
"Previous" button has only a single angle.
3) Apply the patch.
4) Repeat steps 1 and 2.
5) Verify that the "Next" button now has a single angle.
Sponsored-by: Karlsruhe Institute of Technology (KIT)
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test Plan:
1) Set a patron's privacy to "Never"
2) Check out a few items to a patron
3) Check in one item
4) Note the "Print checkin slip" diplays
3) Apply this patch
4) Check in an item
5) Note the option is now missing
6) Set the patron's privacy to "Forever" or "Default"
7) Check in an item
8) Note the print checkins option is back!
Signed-off-by: Andrew Fuerste Henry <andrewfh@dubcolib.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If a patron anonymizes their checkins, the checkin slip cannot retrieve any info to print the checkin slip. We should not show the button in this scenario
Test Plan:
1) Set a patron's privacy to "Never"
2) Note the "Print checkin slip" option in the Print button on the
patrons toolbar displays
3) Apply this patch
4) Reload the page
5) Note the option is now missing
6) Set the patron's privacy to "Forever" or "Default"
7) Reload the page
8) Note the print checkins option is back!
Signed-off-by: Andrew Fuerste Henry <andrewfh@dubcolib.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
