Correct genuine spelling errors identified by the codespell 2.4.x
full scan after the KTD container OS upgrade. Changes are in
comments, POD, strings, and template text across 55 files.
"SAN Ouest Provence" (the French library co-operative and Koha
sponsor) is preserved as a proper noun. Perl copyright lines
receive an inline # codespell:ignore annotation; about.tt files
(contributor attribution pages) are added to the Koha::Devel::Files
codespell exception list so that future uses of "Provence" as a
typo for "Province" are still caught in all other files.
Notable user-visible fixes:
- "submiting" -> "submitting" in authority and bibliographic merge screens
- "deleteable" -> "deletable" in patron exception messages
- "Acquistions" -> "Acquisitions" in reports dictionary
Test plan:
1. Apply patches
2. In the staff interface, go to Cataloguing > Merge records and
confirm the submit button reads "Submitting" (not "Submiting")
3. In the staff interface, go to Authorities > Merge and confirm
the same correction
4. Attempt to delete a patron with outstanding issues and confirm
the error message reads "deletable" (not "deleteable")
5. prove xt/author/codespell.t
=> All tests pass
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch moves a couple of "onclick" event attributes from the
authority merge template, moving the event handling to the JS block.
This patch also fixes the behavior that I assume the click handlers are
meant to have, changing the framework selection. A mismatch of IDs in
the code meant that clicking the radio buttons didn't do anything.
To test, apply the patch and go to Authorities.
- Perform a search for authority records which will return multiple
results, including records with different heading types (e.g. Personal
Name, Topical Term, etc.)
- In the "Actions" menu for one of the search results, click "Merge"
- Do the same with another result which has a different heading type.
- On the "Merging records" page you should see a frameowrk dropdown.
- When you click the radio buttons next to your two records to merge the
framework selection should change to match your selection.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Amended-by: Jonathan Druart
Tidy
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This patch corrects the logic used to determine whether to show the "New
match check" link. I mistakenly changed it to check for the matchpoints
variable instead of the matchchecks variable.
To test, apply the patch and go to Administration -> Record matching
rules.
- Click "New record matching rule" in the toolbar.
- Scroll down to the "Required match checks" section.
- You should see a "New match check" link alongside a "Remove this match
check" link.
- Go back to the record matching rules main page.
- If necessary, create a rule which doesn't have any match checks.
- In the "Required match checks" section of the edit form you should see
a "New match check" link, previously hidden by Bug 388714.
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: Pedro Amorim <pedro.amorim@openfifth.co.uk>
It has been broken then fixed then broken again, several times...
This patch fixes 2 problems:
1. The CSRF fix (I think it's coming from there) didn't adjust the 'if show' test and the JS code from plugins was not injected into the template
2. The selector to call the plugin didn't include this view, only the
add/edit items
Test plan:
Confirm that you can now use cataloging plugins when editing items in
batch
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The self-checkout and self-checkin templates no longer need explicit
inclusion of Font Awesome CSS because it's rolled into _common.scss and
thus sco.scss.
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
It makes more sense to use lib/fontawesome/webfonts as the source
directory for Font Awesome font files rather than bootstrap/css/fonts.
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
We are using Font Awesome 6.3 in the OPAC. The current version is 7.2.
Upgrading will eliminate the repeated warnings in the browser console
about "Glyph bbox was incorrect."
The patch adds Font Awesome to the list of packages in node_modules and
moves the Font Awesome SCSS into _common.scss so that it can be bundled
along with Bootstrap and other 3rd party assets.
Despite the fact that _common.scss grabs FA SCSS files directly from
node_modules I've added the FA font files to css/fonts. I was unable to
see how to reference the webfonts directory in
node_modules/@fortawesome.
The many changed .inc and .tt files are a result of a missed aspect of
our upgrade to Bootstrap 5. The "sr-only" class was removed in BS5 but
the Font Awesome CSS included its own "sr-only" class. This made up for
the fact that we missed the required upgrade to BS5's "visually-hidden."
As soon as Font Awesome's "sr-only" was gone all these mistakes were
made visible.
To test, apply the patch and run 'yarn install.'
- Rebuild the OPAC SCSS.
- Clear your browser cache.
- Test many pages in the OPAC to confirm that no icons are missing.
- Check changes to the templates to confirm that "sr-only" has been
replaced with "visually-hidden."
- Places where a broken "sr-only" class would be obvious: Star ratings
on the user summary page, <legend>s on the search history page.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The Print receipt and Close buttons added in the previous patch use
class="no-print", but printreceiptinvoice.css had no @media print rule
for that class — so they appeared in the printed output (e.g. when
saving as PDF or auto-printing in browsers that block popups).
Add a @media print rule so the buttons remain visible on screen but
disappear from the printed receipt.
Test plan:
1. Disable browser popups (Chrome: "Don't allow sites to send pop-ups
or use redirects").
2. Enable FinePaymentAutoPopup.
3. Complete a POS sale.
4. On the receipt page, choose Print to PDF (or trigger auto-print).
5. Verify the printed/PDF output contains only the receipt body — no
Print receipt or Close buttons.
6. Verify the buttons remain visible on screen.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The previous approach triggered popup blockers because the receipt window
was opened via JavaScript after a page reload — browsers treat this as a
non-user-initiated action. This patch reverses the flow: when
FinePaymentAutoPopup is enabled, the payment form submits directly to a
new tab via target="_blank" (a user-initiated action that browsers allow),
the server processes the payment and redirects (303) to the receipt page,
which auto-prints and closes itself, returning focus to the POS tab.
When FinePaymentAutoPopup is disabled, the server redirects back to the
POS page with payment details in the URL (standard PRG), displaying the
existing success banner with print/email receipt buttons.
Changes:
- pos/pay.pl: Implement PRG redirect for both popup and non-popup flows,
URI-encode redirect parameters, remove session-based state management
- pos/pay.tt: Add target="_blank" when FinePaymentAutoPopup is enabled,
reset form state after submission via same-scope setTimeout
- pos/printreceipt.pl: Add error handling for missing receipts, pass
autoprint parameter to template
- pos/printreceipt.tt: Add conditional auto-print, manual print/close
buttons, error display, and IntranetSlipPrinterJS preference support
- slip-print.inc: Modernize jQuery to vanilla JS, remove obsolete
Chrome setTimeout hack
Test plan:
1. Enable FinePaymentAutoPopup system preference
2. Go to Point of Sale, add items, and complete a sale
3. Verify receipt opens in a new tab without popup blocker warnings
4. Verify receipt auto-prints and tab closes after printing
5. Verify original POS tab form is reset for next transaction
6. Disable FinePaymentAutoPopup
7. Complete another sale
8. Verify POS page shows success with Print/Email receipt buttons
9. Test receipt printing from other pages (circulation, fees) to
confirm slip-print.inc change causes no regressions
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Correct "opac" with "OPAC" in the pref file
Test plan:
git grep opac **/*.pref
and confirm that there is no relevant occurrences in the output (i.e.
no strings displayed on the UI)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
The afterEach calls cy.login() then immediately posts to the syspref endpoint. On CI, the machine is slow enough that the POST fires before the login
redirect completes — no valid session yet — so the endpoint returns a C4::Service auth error in this format:
{ "type": "auth", "message": "expired" }
http-client.js only knew how to parse modern REST API errors (json.error or json.errors[]). Neither field exists here, so json.errors.map(...) crashed with a TypeError instead of surfacing the actual error message.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
waitForJobFinished previously had no handling for failed jobs or
non-200 responses — if the job API returned anything unexpected,
the recursive cy.wait() would silently stall waiting for a 2nd
poll that never came, producing a confusing timeout. Adds an
explicit "failed" status check and updates the intercept
to reproduce the exact CI failure (Apache returning 503 during
reset_all).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Three issues caused the EdifactModal_spec.ts test suite to fail:
1. insertSampleEdifactMessages inserted a vendor with listprice='USD' and
invoiceprice='USD', but those columns have FK constraints against the
currency table and USD is not pre-populated in KTD's default install.
Drop the currency columns from the INSERT so they default to NULL.
2. Koha::Edifact::File::vendor() and basket() called
Koha::Acquisition::Bookseller and Koha::Acquisition::Basket without
use-ing them. The edifactmsgs.pl table embeds both on every API call,
so a missing module caused a 500 and an empty table.
3. showMessage() already appended &format=json before delegating to
showMessageFromUrl(), which then appended it a second time. Remove the
redundant copy from showMessage().
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch updates the identity provider domain page so that clicking
the "Delete" button from the list of existing identity providers works
correctly.
There's a lot of unfinished copy and paste from the SMTP servers page,
including a missing chuck of modal dialog HTML.
To test, apply the patch and go to Administration -> Identity providers.
- If necessary, add at least one identity provider.
- Click the "Manage domains" button for an identity provider.
- If necessary, add at least one identity provider domain.
- Click the delete button corresponding to the domain you added.
- A confirmation modal should appear.
- Clicking "Close" should close the modal without triggering any
action.
- Clicking "Delete" should delete the domain.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch removes several "onChange" event attributes from
marc_modification_templates.tt and moves the event handlers into
marc_modification_templates.js.
The patch also corrects a view minor zxlinting errors in the JS file.
To test, apply the patch and clear your browser cache if necessary.
- Go to Cataloging -> MARC modification templates.
- Create a new template if necessary.
- Click "New action."
- Test the behavior of dropdowns and checkboxes in the new action form.
- Fields should be correctly shown or hidden based on the selected
actions
- Fields should be correctly shown or hidden based on the "RegEx"
checkbox.
- Text the conditional dropdown along with the "matches" dropdown.
- Test that the "matches" regex fields are correctly displayed
according to the checkbox.
- The browser developer console should show no "Content-Security-Policy"
errors.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch updates the CSS which controls the display of the news item
footer ("Posted by" and edit/new links) in order to improve
accessibility.
To test, apply the patch and rebuild the staff interface CSS.
- If necessary, create at least one news item with the display location
"Staff interface."
- On the staff interface home page, look at the news items in the
left-hand sidebar. The "Posted by" line should be clear. A check of
the text's contrast should show that the contrast is appropriate.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Lawrence O'Regan-Lloyd <loreganlloyd@clamsnet.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch removes a couple of "onChange" event attributes from the
lists template in favor of defining the event handler in the footer JS.
To test, apply the patch and go to Lists -> New list.
- Choose "Private" from the public dropdown.
- In the "Allow changes to contents from" dropdown select "Permitted
staff only"
- A note should appear about the setting having no effect.
- You should see a similar note displayed when you select "Staff only"
or "Anyone seeing this list"
Sponsored-by: Athens County Public Libraries
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 moves a couple of "onclick" event attributes from the
bibliographic record merge template, moving the event handling to the JS
block.
This patch also makes a minor change to make sure that the
framework code dropdown preselects the framework of the first of
the records to merge. This brings it in line with the authority
merge template.
To test, apply the patch and perform a catalog search which will return
multiple results including results with different frameworks. In the
standard test data a search for "green" will return two results with two
different frameworks.
- Check the checkbox for at least two records in your search results.
- Click "Edit -> Merge records" in the toolbar at the top of the
results.
- On the "Merging records" page you should see a frameowrk dropdown. It
should have preselected the framework corresponding to the first of
the records you selected.
- When you click the radio buttons next to your records to merge the
framework selection should change to match your selection..
Sponsored-by: Athens County Public Libraries
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1 - Open a basket, place some orders, close the basket
2 - Receive shipments
3 - Select an order and click 'Receive selected'
4 - Nothing happens, error in console
5 - Apply patch, reload page
6 - Can successfully order
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 recreate:
1. Log in to the OPAC
2. Create at least 1 list
3. Go to the "Your lists" page (opac-userlists)
4. Inspect the table header for the Edit/Delete column
5. Confirm the header contains no text
Test the patch:
1. Apply the patch
2. Repeat steps 1-3
3. Inspect the table header for the Edit/Delete column
4. Confirm the header now contains accessible text
5. Confirm Edit and Delete actions still function as expected
6. Run an accessibility checker and confirm the issue is resolved
7. Sign off and have a wonderful day! :D
Signed-off-by: John Vinke <jvinke@austinseminary.edu>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The cancel add authorized value button has no type, so it will submit the form.
This patch makes it a button so it does not submit the form.
Test plan:
1. Ensure that the CreateAVFromCataloguing preference is enabled.
2. Edit an item.
3. Enter an authorized value that does not exist (e.g. shelving location).
4. Select it to be able to create it.
5. Click the Cancel button to not create a new authorized value.
6. Observe that the form was sent or that a new authorized value was created.
7. Delete the new authorized value.
8. Apply the patch.
9. Repeat steps 2-5.
10. Observe that the form was not sent or that a new authorized value was not
created.
11. Sign off.
Sponsored-by: Lund University Library
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
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>
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>
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>