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.