[Bug 43520] New: Replace PatronAutoComplete with PatronSelect in FormElement.vue
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 Bug ID: 43520 Summary: Replace PatronAutoComplete with PatronSelect in FormElement.vue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com Depends on: 43518 Target Milestone: --- Bug 43518 added PatronSelect.vue, a modern Vue 3 / TypeScript patron picker built on vue-select, as a drop-in replacement candidate for the legacy PatronAutoComplete.vue (which wraps jQuery UI's autocomplete widget and the global window.patron_autocomplete()/patron_autocomplete_render_selection() functions). This bug tracks migrating PatronAutoComplete's remaining consumer -- FormElement.vue's generic "patronAutoComplete" driven-form field type -- onto PatronSelect, and closing the gaps that stand in the way: 1. v-model contract mismatch: FormElement.vue binds v-model="resource[attr.name]" as a bare patron ID. PatronSelect's modelValue is a full option object built by patronToOption() (vue/utils/patron-options.js, added in bug 43518). This needs an adapter at the FormElement.vue integration point, or a deliberate decision to change what that field type stores. 2. Initial-selection hydration: PatronAutoComplete fetches and renders the currently selected patron on mount when given an existing ID (used when editing a record that already has a patron attached). PatronSelect has no equivalent built in by design -- it stays side-effect-free -- but bug 43518 added resolvePatronOption() specifically for this: given a bare id it fetches and maps the patron, given an already-embedded patron record it maps only. FormElement.vue's integration needs to call this before/while mounting PatronSelect when editing an existing resource. 3. Confirm parity for anything else FormElement.vue's "patronAutoComplete" field type relies on from PatronAutoComplete (e.g. the patronAutoCompleteOptions "additional-filters" passthrough), and either port it to PatronSelect's query-building convention (reusing the existing buildPatronSearchQuery() global, as bug 41129's booking adapter already does) or document why it does not apply. Out of scope: request.tt calls window.patron_autocomplete() directly (not through the Vue wrapper), so it is unaffected by this migration. Test plan: 1. Apply on top of bug 43518. 2. Find a form rendered via FormElement.vue with a "patronAutoComplete" field (e.g. a plugin custom field, if applicable in your test data), for both create and edit. 3. Verify searching, selecting, and clearing a patron all work, and that an existing selection is shown correctly when editing. 4. Run the existing FormElement.vue Cypress component spec plus any new coverage added for this migration. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43518 [Bug 43518] Add a reusable PatronSelect Vue component with patron search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Narrowed the scope after investigating: patronAutoComplete as a driven-form field type has exactly one real consumer in core -- ILL's Requesting Agency admin screen (RequestingAgencyResource.vue), picking the "ILL partner" patron on an iso18626_requesting_agency record. No plugin in this tree defines one either, so the actual blast radius is a single, niche, optional-module admin screen rather than a broad set of forms. It is rendered across three generic components keyed off the same field config: FormElement.vue (the editable input, this bug's target), ShowElement.vue (read-only detail view) and ResourceList.vue (table column), both of the latter reading an already-embedded patron object off resource[attr.patronEmbedName] and formatting it via the legacy $patron_to_html() -- unaffected by this bug, since neither uses PatronAutoComplete.vue. Usefully, iso18626_requesting_agency's API resource embeds the picked patron by default on GET (x-koha-embed: ill_partner, a formally documented embed per iso18626_requesting_agency.yaml), so the edit form's resource already carries both patron_id and the full embedded patron side by side. That means the "hydrate an existing selection" problem this bug needs to solve is exactly the two-shapes-in case resolvePatronOption() (bug 43518) was built for, and in practice needs zero extra API calls: prefer the embed, fall back to fetching by id only for the (here, never occurring) case where only an id is known. One incidental, unrelated finding: ShowElement.vue's formatPatronHTML() renders $patron_to_html()'s return value via {{ }} text interpolation, not v-html, so any HTML markup in that string would show as literal escaped tags. It happens to render fine today only because no config is passed at that callsite and $patron_to_html()'s title handling is dead code. Not part of this bug's scope (ShowElement.vue doesn't use PatronAutoComplete), just flagging it here since it was found while scoping this work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 205595 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=205595&action=edit Bug 43520: Replace PatronAutoComplete with PatronSelect in FormElement.vue Migrate FormElement.vue's generic patronAutoComplete driven-form field type from PatronAutoComplete.vue (jQuery UI autocomplete plus global window.patron_autocomplete()/patron_autocomplete_render_selection() functions, untestable in the Cypress component sandbox - \$ is not defined) onto PatronSelect (bug 43518). The only current consumer is ILL's Requesting Agency admin screen (RequestingAgencyResource.vue), picking the 'ILL partner' patron on an iso18626_requesting_agency record. Its API resource embeds the picked patron (patronEmbedName: 'ill_partner', a formally documented embed per iso18626_requesting_agency.yaml), so the create/edit form already has both the raw patron_id and, when editing, the full embedded patron side by side. FormElement.vue now owns: - Hydrating the field's current selection: prefer the embedded patron (patronToOption()) and only fall back to fetching by id (resolvePatronOption(), bug 43518) when no embed is present - which in practice is only the never-yet-selected/create case. - Searching: reuses the same global buildPatronSearchQuery() and additional-filters merge the legacy jQuery widget used, via APIClient.patron.patrons.search(), mapped through patronToOption() with { invertName: true, showDiffFirstname, loggedInLibraryId } - matching the legacy autocomplete dropdown's own display convention (surname-first; the syspref-driven legal-firstname aside; current- library highlighting), read from the same js_includes.inc globals the legacy widget already relied on. - Passing the selected option's patron_id back to resource[attr.name], and keeping the embed in sync when patronEmbedName is configured. PatronSelect.vue: made its self-rendered <label> conditional (v-if="label") and added a hideRequiredMarker prop, so it can be embedded inside FormElement.vue's own uniform label/Required-marker layout without producing a duplicate of either. PatronAutoComplete.vue is now unused anywhere in core (confirmed by a full-tree search) and has been removed; the PatronAutoComplete syspref and request.tt's direct window.patron_autocomplete() jQuery call are unrelated (naming collision only) and untouched. Test plan: 1. Apply on top of bug 43518. 2. Run: yarn cypress run --component --browser electron 3. Verify all specs pass, including the new patronAutoComplete coverage in FormElement_spec.ts and the label/marker coverage in PatronSelect_spec.ts. 4. In the staff interface, go to a library with ILL configured and the ISO18626 requesting agencies feature enabled. Add a new requesting agency: search for and select an ILL partner patron, save, then edit the same record and confirm the previously-selected patron is shown immediately (no blank picker). Assisted-by: Sonnet 5 (Anthropic) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matt.blenkinsop@openfifth.c | |o.uk -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacob.omara@openfifth.co.uk -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org