|
initSearchPicker's input handler has always short-circuited on an empty
term -- correct for every existing picker, none of which want results
appearing before anything's typed. The asset picker does want exactly
that (show the last few uploaded images without requiring a search
first), so this adds an opt-in loadOnFocus option instead of changing
the shared default: it fires once when the input gains focus with no
term yet, reusing the same request/render path a real search uses
rather than a separate code path. The AJAX call itself was pulled out
into a named runSearch function so both triggers could share it without
duplicating the success/render logic.
RelatedAssetsController#search now treats a blank term as "show the
most recently created, unattached images" (limit 5) rather than
returning nothing, matching the new client behavior. A real search
term still returns up to 10 name-matched results, unchanged.
|
|
Backend for the asset-picker rebuild -- replaces the plan to dump
every image asset in the system into a hidden, unfiltered browse
panel on every node edit (the actual current behavior, confirmed by
reading nodes/edit.html.erb directly) with a small, name-scoped search
endpoint plus create/destroy/update for attach, detach, and reorder.
No schema change needed -- RelatedAsset already had everything this
requires (asset_id, page_id, an acts_as_list position). search excludes
assets already attached to the page, keeping results meaningfully small
given hundreds of assets total but only a handful per node in practice.
create is find_or_create_by! rather than a bare create!, guarding
against the same asset being attached twice from two separate search
results. update leans on acts_as_list's own insert_at rather than
custom position-shifting logic.
Node#editable_page (autosave || draft || head) is extracted since this
is now its third call site with identical logic -- deliberately not
touching nodes#show, which resolves draft || head without autosave on
purpose, a different and correct semantic for "current committed
state" versus "what's actively being edited."
|
