[pendingintent]

Summary

Closes #83. As a BC/DSS curator, copy an existing BC or Specialization and tweak the group-level info while keeping its DECs/variables.

Design confirmed with the repo owner:

• Clone pre-fills the existing New BC / New Specialization form from a source record (group-level fields, DECs/variables), with the ID left blank — nothing is saved until the curator edits and hits Save. Reuses the existing create_bc()/save_decs() and specialization create() write paths unchanged.
• BC clone is scoped to the BC + its DECs only; specializations are cloned independently via their own action (treats BCs and Specializations as parallel, independent requests, not a cascading operation) — confirmed as the desired scope.
• DECs travel along automatically as part of a BC clone; no standalone per-row DEC duplicate control was added — confirmed not needed.
• Carried-over fields (including package_date and parent_bc_id) are copied verbatim, same as every other field, and remain editable before Save — confirmed no special-casing wanted.
• Clone is exposed both as a list-row action and a detail/edit-page action.

Changes:

• services/bc_service.py — build_bc_clone(bc_id): returns a transient (unsaved) BiomedicalConcept + DEC dicts copied from an existing BC. Each DEC's dec_id is blanked so save_decs() regenerates it under the new bc_id on save, instead of keeping a stale <old_bc_id>.DEC.N.
• routes/bc.py — GET /bc/new?clone_from=<bc_id> renders the New BC form pre-filled from the source (or flashes + redirects to the list if the source doesn't exist).
• routes/specializations.py — GET /specializations/?clone_from=<vlm_group_id> pre-fills the New Specialization panel (auto-expanded) from the source, without touching vlm_group_id or the existing edit-in-place path.
• templates/bc_detail.html — the DEC table now renders from the decs route variable instead of bc.decs (needed because a transient clone object isn't session-bound, so its decs relationship can't be queried); adds a Clone button + a "cloned from" banner.
• templates/specializations.html — introduces a shared fs (edit_spec or clone_spec) variable for prefill, while keeping vlm_group_id and the published-lock checks scoped to true edit-in-place only; adds a Clone row action.
• templates/bc_list.html — adds a Clone row action.

Test plan

• New tests: TestBuildBcClone (bc_service), TestCloneBc (bc routes), TestCloneSpecialization (specializations routes)
• Full suite: pytest --tb=short — 492 passed (independently re-verified)
• isort / black / flake8 clean (independently re-verified via pre-commit run --all-files)
• CI green including CodeQL (independently re-verified)
• Manual smoke test against a throwaway DB: created a source BC with a DEC and a source Specialization with a variable, fetched both clone-prefilled forms, verified the ID fields were blank while other fields/DECs/variables were prefilled, submitted each under a new ID, and confirmed both the source and the clone exist as independent records with correctly-regenerated DEC ids (not carrying over the old bc_id prefix)

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[pendingintent]

@claude review

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

🟡 (optional) Cloning a BC copies ncit_metadata/loinc_metadata verbatim (build_bc_clone, services/bc_service.py:29) into hidden fields that a New BC form previously always left empty. If the curator types a different ncit_code or loinc_code by hand instead of re-running the lookup — JS only refreshes the hidden metadata via an explicit search-and-select (static/js/main.js:191,1078) — apply_bc_fields (services/bc_service.py:44-56) saves the new code paired with the old concept's stale metadata. Fix: blank ncit_metadata/loinc_metadata on clone like dec_id already is, or clear them server-side whenever the submitted code differs from the code that produced them.

Extended reasoning...

GET /bc/new?clone_from=C100 renders bc_detail.html with is_new=True: ncit_code text input prefilled 'C100' (line 161-162) and hidden #ncit_metadata prefilled with C100's saved NCIt JSON (line 145), because build_bc_clone copies loinc_metadata/ncit_metadata verbatim onto the transient clone. Before this diff, is_new=True BC() objects always had ncit_metadata=None, so this hidden field was always empty on New BC — the mismatch could not occur there; the clone path is what newly enables it. Curator edits the ncit_code input to 'C200' by hand — a natural way to 'tweak group-level info' — without clicking Look up NCIt. No listener clears #ncit_metadata on input to #ncit_code (static/js/main.js:84-126); only the 'Use this concept' handler (line 191/192) or the fetch-metadata block (gated on bc.bc_id, so it never runs for is_new) update it. On submit, apply_bc_fields' is_new branch sets bc.ncit_code='C200' but bc.ncit_metadata=the stale JSON describing C100, persisting a BC whose code and displayed NCIt metadata describe two different concepts. The identical mechanism applies to…

Verification: nit. The mechanism is real and reachable but low-impact. build_bc_clone copies ncit_metadata/loinc_metadata verbatim (services/bc_service.py:29, 105-115). The clone route renders bc_detail.html with is_new=True and this object (routes/bc.py:73-84), and the template prefills hidden #ncit_metadata (bc_detail.html:145) plus the visible ncit_code input (bc_detail.html:161-162). JS refreshes…

[pendingintent]

Clone functionality added to Biomedical Concepts and Data Set Specializations.