If some plugins are installed and inject REST API routes, xt/api.t may fail.
Test plan:
You can install the Jump plugin (https://gitlab.com/joubu/koha-plugin-jump) and run xt/api.t
It will fail:
```
get /contrib/jump/parse -> uses tag 'parse' not present in top level list
get /contrib/jump/search -> uses tag 'search' not present in top level list
get /contrib/jump/search -> uses tag 'objects' not present in top level list
get /contrib/jump/static/static_files/commandPalette.js -> uses tag 'Jump' not present in top level list
get /contrib/jump/static/static_files/jump.css -> uses tag 'Jump' not present in top level list
[...]
```
Apply this patch and run `prove xt/api.t` again
=> It should pass
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We must use t::lib::Dates::compare to compare dates in test.
Test plan:
Confirm that `prove t/db_dependent/Koha/Hold.t` still returns green
after this patch
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If you try to login from suggestion/suggestion.pl you get a 500
DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception:
DBD::mysql::st execute failed: Unknown column 'login_op' in 'WHERE' at
/kohadevbox/koha/Koha/Objects.pm line 401
Test plan:
Logout
hit /cgi-bin/koha/suggestion/suggestion.pl
login
=> Without this patch you get a 500
=> With this patch applied you get the suggestion list view
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The multipleSelect plugin is used on the ILL requests table but is not
present when viewing a patron's ILL request history. This patch avoids a
JS TypeError by checking if the plugin exists before calling it.
To test:
- Enable ILLModule setting
- ILL Requests > New ILL Request
- Metadata doesn't matter but attach to a patron account, e.g. use the
"Acevedo" surname on KTD
- Go to the Patron > ILL requests history
- View browser's JS console, note TypeError
- Apply patch
- Refresh page, TypeError goes away
Signed-off-by: Chris Mathevet <chris.mathevet@inLibro.com>
Amended-by: Jonathan Druart
Tidy
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan :
- Disable all but one language in system preference
StaffInterfaceLanguages
- Start a local instance of Mana
- Clone the mana repo on your machine (from
https://gitlab.com/koha-community/koha-mana)
- Edit compose/base.yml and uncomment the line:
${PWD}/sql/mana-sample.sql:/docker-entrypoint-initdb.d/test-data.sql
- Run `bin/mana --skip-email-validation up -- -d` to launch mana and
create a docker network koha will connect to
- Run `ktd --mana up -d` to connect koha to mana
- In Koha staff interface, go to "Administration » Share content with
Mana KB":
- Set "Share content with Mana KB" to "Yes", click "Save"
- Fill the form under "Configure Mana KB", click "Send to Mana KB"
- Try to share a report to mana. Go to Mana UI to verify that the report
was correctly shared
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Emmanuel Bétemps <e.betemps@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When UseCashRegisters is enabled and a change value bigger than 0 exists (the amount tendered is bigger than the amount paid) the form could be submitted without a required cash register.
The modal dialog informing of the change value would simply ignore missing other required fields.
Also warnings on 'Amount tendered' did not disappear when 'Amount being paid' was set to a higher value and later reset to a lower value than 'Amount tendered'.
This patch fixes both issues by moving the modal dialog (confirm change money) to the form validations submit handler and by validating the form on each update of 'Amount tendered' or 'Amount being paid'.
Test plan:
a) enable UseCashRegisters and create one under /cgi-bin/koha/admin/cash_registers.pl?op=add_form
b) create a manual fee (f.e. 10) f.e. via /cgi-bin/koha/members/maninvoice.pl?borrowernumber=16
c) There are several ways to reach the 'Pay an amount toward all charges' form:
- Patron -> Accounting -> (Tab) Make a payment
- Patron -> Details -> Attention -> Pay all charges
d) enter the follwing values
- Amount being paid: 7
- Amount tendered: 6 -> a warning will appear : Please enter a value greater than or equal to 7.
e) set
- Amount being paid: 5 -> The warning remains visible: Please enter a value greater than or equal to 7.
f) Click confirm -> Modal which wants you to confirm that there is a change left.
g) Click yes. The form will be sent even though the required filed 'Payment type' is not set.
h) go to the payments form again. Total amount outstanding should be 5.00 now
enter the following so that change is > 0.00
- Amount being paid: 3
- Amount tendered: 4
- Payment type: Cash
i) Click confirm -> Modal which wants you to confirm that there is a change left.
j) Click yes. You will see an Error trace page
As long as 'Change to give' is other than 0.00 you will be able to send the form.
Apply patch:
l) repeat b) until e) and check that the warning disappears when Amount being paid is lower or equal than Amount tendered
m) check that clicking Confirm will not send the form
n) check that when Payment type is set to Cash, the Cash register is required to send the form.
Signed-off-by: David Nind <david@davidnind.com>
Amended-by: Jonathan Druart
Tidy
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch reimplements form validation on news (additional contents). The form.validate() call which adds a submitHandler is moved outside the document ready block in order to work again.
Markup like class=required is added to meet JS10 guidelines. JS alerts (when default title or default content was empty) were replaced by setting focus the required field.
Test plan:
a) go to /cgi-bin/koha/tools/additional-contents.pl?category=news (Tools -> News)
b) click either 'New entry' or 'New entry using text editor'
c) enter a required publication date
d) save the form. You will not be required to enter a default title or content.
e) apply patch followed by a restart_all
f) go to /cgi-bin/koha/tools/additional-contents.pl?category=news (Tools -> News)
g) click either 'New entry' or 'New entry using text editor'
h) check that title and content in the 'Default' tab are marked as required
i) try to send form f.e. when only title and content in 'English' tab are set
j) check if default title or content is missing the default tab is shown and the field gets focused
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1 - enable DisplayAddHoldGroups
2 - place two ungrouped holds for a patron
3 - log into the opac as your patron, see 2 pending holds
3 - group the two holds
4 - reload OPAC, still see 2 pending holds
5 - Apply patch, restart_all
6 - reload OPAc, see 1 pending holds
7 - ungroup holds
8 - reload OPAC, see 2 pending holds
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
prove t/db_dependent/Reserves.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Make 'Maximum total holds allowed (count)' (aka max_holds) consider hold groups
Test plan:
Same as the previous test plan, but set 'Maximum total holds allowed (count)' as 2 and instead set 'Holds allowed (total)' as unlimited.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Make 'Holds allowed (total)' (aka reservesallowed) consider each hold group as an individual hold
Test plan:
1) Enable DisplayAddHoldGroups sys pref
2) Set Holds allowed (total) to 2, visit:
http://localhost:8081/cgi-bin/koha/admin/smart-rules.pl
3) Scroll to the right, click the 'Edit' button under 'Actions' column.
4) On the 'Holds allowed (total)' column cell, enter '2' and click 'Save' under the 'Actions' column to the right.
5) Search for 'test':
http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=test
6) Tick the checkbox next the first and second results, click 'Place hold' button at the top toolbar
7) Search for 'koha' user and pick Koha (42)
8) Set a pickup location for each hold and tick the 'Treat as hold group' checkbox. Click 'Place holds'.
9) Try to place another single hold for the same patron. Should succeed, because the 2 grouped holds count as 1. Patron now should have 1 group + 1 ungrouped hold = effective count of 2.
10) Try to place yet another hold, should be blocked with a tooManyHolds error.
11) Prior to this patch, step 9 would've failed because the 2 grouped holds counted as 2.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
An exception is not implemented as progress_request is called in
different circulation contexts (hold is placed, checkout happens,
etc) and those actions should not be dependent on the outcome of
progress_request, i.e. if progress_request fails due to schema
validation failure, the circulation action should happen as before.
prove t/db_dependent/Koha/ILL/ISO18626/Request.t
prove t/db_dependent/api/v1/iso18626/request.t
cypress run --spec t/cypress/integration/ILL/SupplyingRequests.ts
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This reimplements how patronAutoComplete behaves on ShowElement, keeping the same functionality but dropping v-html
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The v-html directive was unintentionally left on the fallback <template>
in LinkWrapper during the introduction of the ILL module. It has no
effect and should not have been committed.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This is leftover from original implementation of progressRequest when it was it's own component.
All functionality is now in SupplyingResourve.vue instead
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This is leftover from original implementation.
It since moved to js/vue/stores/ill.js and is managed by ILL/Main.vue
To test:
1) Access (with ILLModule enabled and disabled):
http://localhost:8081/cgi-bin/koha/ill/ill.pl
2) Confirm you get the module if ILLModule is enabled, or a message if
it's disabled
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This was leftover from a previous approach at implementing it, before
hooking into holds/circulation was entirely holds authoritative.
As it currently stands, the note and expectedDeliveryData form inputs are
rendered and handled by the request.tt form when placing a hold, if a
supplyill param exists.
The params are then sent to AddReserve by placerequest.pl which in turn
sends it to progress_iso18626_request.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Adds a generate next button to the serials receive page (serials-edit.pl) that works similar to the button on the serials collection page.
To test:
1. Go to Staff Client > Serials
2. Find an existing subscription or create a new one
3. Go to the Serials collection page for your serial e.g. /cgi-bin/koha/serials/serials-collection.pl?subscriptionid=1
4. Click on the "Generate next" button and notice that the table adds
another row
5. Click on the "Receive" button at the top of the page
6. Notice that the page also shows the issues like the rows in the
previous page
7. Apply patch
8. Repeat steps 1-5
9. Notice that the page also has a "Generate next" button at the top
10. Check that the button generates a new issue row on the page
Sponsored-by: Pymble Ladies' College
Signed-off-by: esther <esther@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This splits the script tag in two_factor_auth.tt and member-flags.tt to have a seperate part for interploated TT variables.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In order to tidy all the script tags of the .tt files we isolate the
interpolation of Template::Toolkit variables in a separate script tag.
This patch focuses on the members/patrons module.
The 2 main changes are in the following files:
* moremember.tt
=> Trivial, simply moving the existing JS variable to a separate script tag
* update-child.tt
=> Trivial, only a single variable created: 'patron_id'
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
- The explicit `export { h }` from the "Re-export h" follow-up
conflicts with `export * from "vue"` added in the "Share Vue
via import map" follow-up, since the wildcard re-export already
includes h
- Remove the redundant named export to fix the rspack build error:
"Duplicate export of 'h'"
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The QA test tools require all <script> elements to have a
src or nonce attribute. Import maps are declarative JSON and
not executed as code, but adding the nonce satisfies the
check and is harmless.
To test:
1. Run qa-test-tools on the patch set and verify all files
pass the forbidden_patterns check.
2. Load any staff page and verify the import map still works
(Vue islands render, plugin islands have reactivity).
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If a plugin's importFn returns null or undefined (e.g. the
static file was removed or the import fails silently), the
frozen module clone would crash with "Cannot convert undefined
or null to object". This adds an early return before the
clone attempt.
To test:
1. Register an island with an importFn that returns undefined.
2. Verify no error is thrown and the island is silently skipped.
3. Other islands on the same page still render normally.
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Plugin-provided Vue SFCs need access to the same Vue runtime
that Koha uses for defineCustomElement. Without this, plugins
bundle their own Vue, creating two reactive systems that do
not interoperate (reactivity breaks silently).
- Re-export all of Vue from islands.esm.js so it serves as
the single source of Vue APIs
- Add import map in main-container.inc mapping "vue" to
islands.esm.js — plugin builds that externalize Vue now
resolve to Koha's shared instance
- Clone frozen ES module exports before passing to
defineCustomElement (module namespace objects are frozen
per spec, but defineCustomElement needs to set properties)
To test:
1. Verify existing core islands still render (admin-menu,
acquisitions-menu, vendor-menu).
2. Install the test plugin (test-islanddemo-0.1.0.kpz).
3. Navigate to any staff page and verify the Vue Island
Demo component renders with styling.
4. Click the counter button repeatedly and verify the count
updates reactively.
5. Open browser console — no errors except CSP report-only
warnings.
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Plugins that register inline islands need Vue's h() function
to build render trees without requiring a separate Vue import
or the template compiler. Re-exporting h from the islands
module lets plugins import everything they need from a single
source.
To test:
1. From a plugin's intranet_js module script, import h:
const { registerIsland, h } = await import(islandsSrc);
2. Use h() in a component's setup/render function.
3. Verify the component renders without the "runtime
compilation is not supported" warning.
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Reject names that do not conform to the web component spec
(lowercase, must contain a hyphen, must start with a letter).
This catches typos early with a clear console warning rather
than letting them fail silently or throw at customElements.define().
To test:
1. Call registerIsland("InvalidName", { ... }) and verify
a warning is logged and registration is rejected.
2. Call registerIsland("no-problem", { ... }) and verify
it succeeds.
3. Call registerIsland("123-bad", { ... }) and verify it
is rejected (starts with digit).
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Add a public API to the islands module so that plugins can
register Vue components as custom elements. Plugin JS from
the intranet_js hook runs before hydrate() fires, so
registrations are picked up during the DOM scan.
The function includes a duplicate guard, attempting to
register a name that already exists logs a console warning
and is a no-op, so plugins cannot overwrite core islands.
The WebComponentDynamicImport type is also exported so that
TypeScript consumers get type safety.
To test:
1. Verify existing islands work unchanged:
a. Navigate to Administration and confirm admin-menu
renders.
b. Navigate to Acquisitions and confirm acquisitions-menu
and vendor-menu render.
2. Create a test plugin with an intranet_js hook that
outputs a module script calling registerIsland() with a
simple inline Vue component served via static_routes.
3. Place the matching custom element tag in a template.
4. Load the page and verify the component renders.
5. Open the browser console and verify no errors.
6. Call registerIsland() with an already-registered name
and verify the console warning appears and the original
component is unchanged.
7. Remove the custom element tag from the template and
verify the component is not loaded unnecessarily.
8. Sign-off
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Miranda Nero <mnero@oslri.net>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Miranda Nero <mnero@oslri.net>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Miranda Nero <mnero@oslri.net>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This set of patches adds a new is_fast_add column to biblio_framework.
The Biblio.pm subroutine can_be_edited now checks if the framework is_fast_add.
In Admin > MARC bibliographic frameworks admin users can add or edit
frameworks to be used as Fast add frameworks.
Users with only fast_cataloging permission will be able to add records
using those frameworks in the Fast Cataloging module.
Test plan:
Apply patches, restart_all and updatedatabase
1. Go to Admin > MARC Bibliographic frameworks
2. Edit/create a new framework and check the 'Use as Fast add Framework' box
3. Also edit a framework and uncheck the 'Use as Fast add Framework' box
4. Notice a 'Fast add' badge is displayed in the table
5. Create a staff user with only fast_cataloging permissions
6. Log in as that user and go to Cataloging > Fast Cataloging
7. Confirm you can add a Fast add record and items
8. Use the 'Settings' drop down to Change Fast add framework
9. Confirm you see the frameworks that you set as Fast add earlier
10. Confirm you can add the record and items
11. Log in as a superlibrarian and confirm that you can add records and items
using standard frameworks and frameworks set as fast add
12. Set some biblio frameworks as Fast Add frameworks
13. Login as a user with fast_cataloging permissions only
14. Create and edit different types of Fast Add records
15. Add items and edit items
16. Confirm that you can only edit bibs and items
for bibs where the framework is set as a Fast add framework
and the item is from your home library.
17. Log in as a superlibrarian
18. Confirm you can still create and edit records with the Default
and other frameworks
19. Change a record's framework from a Fast add to Default
20. Login as the user with only fast_cataloging confirm that you can
no longer edit that record or its items
Sponsored-by: CLAMS
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Miranda Nero <mnero@oslri.net>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Miranda Nero <mnero@oslri.net>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Miranda Nero <mnero@oslri.net>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Miranda Nero <mnero@oslri.net>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Jonathan Druart
Eric Phetteplace
elias
Jan Kissig
Andrew Fuerste Henry
Pedro Amorim
Lucas Gass
David Cook
wainuiwitikapark
Paul Derscheid
pders01
Brendan Lawlor