This patch fixes the markup in the modal, introduced by Bug 32581,
asking whether to update the patron's expiration date when changing the
patron category. The markup needs to be updated to conform with
Bootstrap 5.
To test, apply the patch and go to Patrons.
- Search for any patron and edit it.
- Scroll down to the "Library management" section.
- Change the category.
- You should see a confirmation modal: "Confirm expiration date"
- Test each of the controls to confirm that they work correctly: The
"X" close button, the "Yes" and "No" buttons.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch makes changing the expiration date optional, by providing a modal when switching a patron category. Confirming the modal will change the expiration date to the default and cancelling will keep the same expiration date.
To test:
1) Same plan as before except now there is a modal when changing the patron category.
- Attempt confirming the modal: expiration date should change to default.
- Attempt canceling the modal: expiration date should stay the same
Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
To test:
1) In Administration-> Patron categories, set the enrollment period for the 'School' category to 12 months.
2) Find a patron that is from another category, edit their info and change their category from patron to school.
3) Note that the expiry date automatically changes to 12 months from today.
4) Save your changes and ensure on the patron's detail page that their expiration date was successfully changed.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
When creating an analytical record from scratch and filling the 773
field with marc21_linking_section.pl plugin, the information put
in field 773 is very basic, incomplete, sometimes buggy ($9, $0).
Test plan
=========
1. Configure a MARC bibliographic framework: enable essential
subfields in 773: 7, a, t, b, d, g, k, x, z, w (check the Editor
checkbox), put them in this order, and chose plugin
marc21_linking_section.pl for 773 $t.
2. Start creating a new record and go to 773 $t. Activate the plugin
to find the a record to become the host record (perform a search
for 'Linux kernel development'). Note the content of the 773
field.
3. Apply the patch, restart plack etc.
4. Repeat p. 2.-3. See that the generated 773 field contains now much
more information, including 773 $7.
Additionally, commented code has been removed and check/variable
initialization added to get rid of warnings in log.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
The AuthClient template plugin was causing 500 errors during database
upgrades when the identity_providers schema was out of sync. The plugin
tried to query the new 'auto_register_opac' column before the database
schema was updated, creating a chicken-egg problem.
This patch wraps the database query in Try::Tiny to handle schema
mismatches gracefully during upgrades, allowing the upgrade process
to continue without crashing the authentication interface.
Test plan:
1. On main, apply all bug 37711 patches BUT THIS ONE
2. Simulate an upgrade by:
* Edit Koha.pm so it points to the next version
* Move the atomicupdate file to the right number in db_revs
3. Restart everything:
$ ktd --shell
k$ restart_all
4. Access http://kohadev-intra.localhost
=> FAIL: You get a 500! With a stack trace!
5. Apply this patch
6. Repeat 3 and 4
=> SUCCESS: No 500 error, redirects to installer
7. Proceed with the upgrade:
=> SUCCESS: It works as it should
8. Run tests:
k$ prove -v t/db_dependent/Template/Plugin/AuthClient.t
=> SUCCESS: All tests pass
9. Sign off :-D
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch adapts the `Identity provider domains` CRUD page to handle
the new configuration options.
To test:
1. Have an IdP with some domains set. Make sure there's at least one
domain with auto-register enabled and one with it disabled.
2. Apply this patches
3. Run:
$ ktd --shell
k$ updatedatabase
=> SUCCESS: Updates successfully
4. Run:
k$ yarn build
5. Refresh the IdP domains page
=> SUCCESS: The domains table shows both OPAC and staff auto-register
options.
=> SUCCESS: The staff auto-register is disabled for both domains
=> SUCCESS: The OPAC auto-register matches what was set for each domain
regarding auto-register (remember that before this patchset,
auto-register only works for the OPAC).
6. Play with editing/adding/removing domain configurations
=> SUCCESS: Things work as expected, values are persisted on the DB
correctly.
7. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Before this patches, only OPAC auto-registration at login using
OAuth2/OIDC IdPs was allowed.
This patch makes the staff interface to be able to auto-register new
users.
On doing it, I had to track down the possible values for the `interface`
parameter in the case of the staff interface.
Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked
with it. The whole area needs more param validation and exceptions to
avoid mistakes for not knowing the valid values.
I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers.
They get tested on the added tests.
To test:
1. Apply this patch
2. Run:
$ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t
=> SUCCESS: Tests pass!
3. Have a valid OAuth...
4. Enable Staff auto-register
5. Login with an external IdP on the staff interface
=> SUCCESS: It gets registered!
Note: it will probably lack permissions to access the staff interface,
but you can check on the DB it got registered.
6. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch makes the API representation of the identity providers
domains match the new metadata.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch adds sorting to lists of lists in the OPAC.
The mechanism used here for op=list is similar to the one
used in op=view, so it's stylistically and functionally
consistent with the rest of the Lists module in the OPAC.
Test plan:
0. Apply the patch and restart Plack (ie koha-plack --restart kohadev)
1. Create 20+ public lists and 20+ private lists for a particular user
you control (try to use names that range throughout the alphabet)
2. Using SQL, update the Modification date for at least 1 public
list and 1 private list
3. As an anonymous (ie not logged in user), go to
/cgi-bin/koha/opac-shelves.pl?op=list&public=0
4. Note you cannot see any lists
5. Go to http://localhost:8080/cgi-bin/koha/opac-shelves.pl?op=list&public=1
6, Note you can see public lists with a toolbar with the button "Sort"
below the alert "Log in to create a new list"
7. Using the "Sort" option, try out all the different sort options
for default, "List name", and "Modification date"
8. After sorting, try paging through the list of lists. You should
note that the sorting is retained through the paging.
9. prove t/db_dependent/Virtualshelves.t
10. Celebrate!
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch updates the plugin wrapper to include the reports menu and have the breadcrumbs list reports instead of admin or tools when method="report"
To Test:
1. Install the Kitchen Sink Plugin
2. Navigate to Reports->Report plugins->Run Report.
3. Observe the admin menu shows
4. Apply the patch
5. Repeat step 2
6. Observe the report menu shows and the breadcrumbs are for the report module.
7. Check that the tools and configuration show the appropriate tool/admin context.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
cypress run --spec t/cypress/integration/ERM/Dialog_spec.ts
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This ensures that when the dialog is closed, even when clicked outside of it, the messages are correctly removed, same as if the 'close' button had been clicked.
Test plan:
- create a data ERM provider /cgi-bin/koha/erm/eusage/usage_data_providers/add
- dummy data should be sufficient
- then go to data providers list /cgi-bin/koha/erm/eusage/usage_data_provider
- open web development tools console (F12 firefox)
- click on "Run now"
- dismiss dialog by clicking outside the modal!
- click again on "Run now"
- check the logs for errors
- any other clicks to create a modal won't work now ("run now", "delete")
Apply patch. run yarn js:watch or yarn js:build. Repeat.
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch prevents span elements being filled with "undefined"
which are then shown to screen readers and print output.
Test plan:
0. Apply the patch
1. Enable the following system preference: OpacStarRatings (results,
details, and patron).
2. Check out an item to a user you can log in as (e.g. koha user)
3. Go to /cgi-bin/koha/opac-user.pl in the OPAC
4. Click "Print" on the toolbar above the summary table
5. Note that 5 occurrences of "undefined" do not appear next to the
title in the print output
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
So we deal with punctuation like in other places.
If your autocomplete results include a patron without a surname,
Koha still puts a comma and space between the first name and the nonexistent surname, like ", Henry."
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
As I traversed the REST API spec to add the `late_since_days` embed
option, I noticed an inconsistency in the embed options we defined in
each place a basket is to be returned.
This patch makes all the places have the same embed options.
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch adds the option to embed the return value of the
`late_since_days` method in basket objects in the REST API.
It does so by just adding it to the list of embeds in the spec. It is
added in every place baskets can be returned.
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
- Use devtool: false to prevent emitting source maps for cypress.
- Add package script to clean built assets, artifacts.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Replaced the eager imports in the intranet APIClient aggregator with
lazy proxies so individual client modules are only fetched the first
time they are actually used.
Documented the pattern in the createClientProxy JSDoc, and kept the legacy
synchronous API intact by forwarding property access, method calls, and
promise chaining. The Vue aggregator remains on static imports for now
because the rspack bundles already would handle chunking (which we need to configure)
and would require broader consumer changes.
This is a bit hacky, but only touches the api-client itself, which I like.
Otherwise we would have to adjust all consumers.
Test plan:
1. Log in to the staff interface and visit Admin → System preferences.
2. Open DevTools, Network tab, and enable “Disable cache”.
3. Trigger an API call (e.g. edit a preference and click “Save”, or run
await APIClient.sysprefs.sysprefs.update_all({}).catch(()=>{}); from
the console).
4. Confirm a new request for js/fetch/system-preferences-api-client.js
appears and the page still behaves as before.
5. Theoretically we would need to test all call sites..
6. Sign-off
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
In the staff interface we set the class for the patron's title (Mr/Mrs/etc) to "patron_title," but we were making it "patron-title" in the OPAC. This patch standardizes them.
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch adds a wrapper function in patron-title.inc that can be used to either span, or not if no html requested
It replaces the same concept that was used for patron title
to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title
5 - Check page titles, patron search, placing a hold, patron search and confirm different links and views work as before
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
And move the comment where it belongs.
More changes on 41031.
Test plan:
Add a new biblio record with basic editor.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Development wise it is much simpler to do this check in perl when
opening the editor than getting this logic into the template with
javascript. Furthermore, older data may be corrupted, but we trust
the current plugins to not insert such fields anymore.
Test plan:
Run t/db_dependent/Koha/Biblio/Metadata/Extractor/MARC/MARC21.t
Open an existing record in the basic editor. Shorten 008 without plugin.
Save and open the record again. Do you get the alert?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
The command currently logs when deleting indexes and indexing records, it would be helpful
to have a log when resetting the mappings, and to log which mapping file has been used.
To test:
1 - perl misc/search_tools/rebuild_elasticsearch.pl -r
2 - No log of reset
3 - Apply patch
4 - perl misc/search_tools/rebuild_elasticsearch.pl -r
5 - Note reset is logged
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This test ensures that when extended attribute validation fails during
patron creation via the API, no welcome email is sent. This validates
the fix where extended_attributes() validation was moved before the
welcome email is enqueued.
Test plan:
1. Apply this patch
2. Run: prove t/db_dependent/api/v1/patrons.t
3. Verify all tests pass, including the new test that confirms no welcome
email is sent when extended attribute validation fails
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Test Plan:
1. Configure Koha with: AutoEmailNewUser = "Send" and create a mandatory extended attribute that will cause validation to fail; for example, set for the attribute to display in the OPAC, to be editable in the OPAC, and to be mandatory. That means this bug must be tested before Bug 40220, where the validation failure is resolved.
2. Setup your Postman, or any other mock API software, to obtain an OAuth token (/api/v1/oauth/token) and to register a patron (/api/v1/patrons).
3. With the OAuth token, send a POST request to /api/v1/patrons with valid patron data and invalid or missing mandatory extended attribute data.
4. Observe the API response with the 400 error and notice that the welcome email was delviered despite the fact that no patron account was created.
5. Apply the patch and repeat step 3. Notice that the API response still contains the 400 error, but no welcome email was sent.
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
I just added an exception in the script. Sorry for the inconvenience.
Test Plan:
1- Enable the following system preference: OpacStarRatings (results,
details, and patron).
2- Apply the patch.
3- Go to the Opac.
4- Search a record.
5- Inspect the HTML code before the stars and notice that there is "Star
rating" in a span tag with the class "sr-only". Inspect the stars,
there should be a span tag for each star. After the stars, notice
that there is the average rating in a span with the "sr-only" class.
6- Click on a record and do the same as the 5: go to the star rating,
inspect the HTML code, and notice that there is a span tag for each
star.
7- Now, log into an account.
8- Search a record.
9- It should be the same information as in the step 5.
10- Click on a record to view the details. Now, you can change the
rating. Inspect the stars, each should have the number of stars in
the span tag with a "sr-only" class, which are in the link tags.
11- For this part, you need to have a record checked out (if you don't
have a record checked out, go to the staff interface and do it.
Choose your patron and enter the barcode of the record).
12- Go to your account. In the "Checked Out" section, you should see the
same as in the 10 step: the number of stars and be able to change
your rating or make a new one.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This change prevents CSRF on opac-patron-consent.pl by
adding checking of the "op".
Test plan:
0. Apply the patch and koha-plack --restart kohadev
1. Set system preference PrivacyPolicyConsent to "permissive"
2. Log into the OPAC and go to this path:
/cgi-bin/koha/opac-patron-consent.pl?check_GDPR_PROCESSING=1
3. Note that it doesn't change the consent
4. Go to this path:
/cgi-bin/koha/opac-patron-consent.pl?check_GDPR_PROCESSING=0
5. Note that it doesn't change the consent
6. Click the "Yes" radio button and click "Save"
7. Note it changes the consent to Yes
8. Click the "No" radio button and click "Save"
9. Note it changes the consent to No
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch moves the cypress test into the Acqusitions folder to help keep t/cypress/integration organized as we add more tests.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This change validates the displayby parameter in suggestion.pl
in order to prevent SQL injection.
Test plan:
0. Do not apply the patch
1. Log into the staff interface
2. Visit the path /cgi-bin/koha/suggestion/suggestion.pl?
op=else&displayby=status+AND+EXTRACTVALUE(1,CONCAT(0x7e,@@version))
3. Notice a 500 error is generated
4. In the error logs, the MySQL version number will appear
5. Apply the patch
6. koha-plack --restart kohadev
7. Visit the path /cgi-bin/koha/suggestion/suggestion.pl?
op=else&displayby=status+AND+EXTRACTVALUE(1,CONCAT(0x7e,@@version))
8. Notice that no error is generated
9. Try each of the "Organize by" options on the left nav bar
10. Note that none of them generate an error and that the option is
retained after clicking "Go"
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
It is a requirement to have id and class on the body tag. We had a test
that was incorrectly removed (see bug 41216)
Test plan:
Confirm that now reserve/request.pl and reserve/hold-group.pl have the
class "reserve" on the body tag.
Note that reserve/request.pl previously had "catalog", that feels wrong,
please let me know if you disagree with "reserve"
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>