Add subject merge request flow tool

[KrishnaShuk]

ref: #65

Summary

Adds a subject merge request flow that follows the existing community edit request workflow.

What changed

• Adds subject selection from subject search results
• Adds a dedicated /subjects/merge page
• Stores subject merge requests in community_edits_queue as SUBJECT_MERGE
• Adds subject filtering in the community merge request table
• Adds UI tests for subject selection and merge action behavior

Current behavior

This branch creates and tracks subject merge requests, but it does not yet execute the actual
subject record merge.

Pending work

• Implement the actual subject merge execution path.
• Decide how subject redirects or canonical subject resolution should work after merge.
• Add approval flow behavior for subject requests if it should differ from work and author merges.
• Add broader test coverage for the full request lifecycle.

Video

Screencast.from.2026-06-03.00-00-47.mp4

Notes

This is meant to establish the direction of the tool and the queue integration first, before
wiring in the final merge execution.

[accesslint]

Found 4 issues across 1 rule.

[accesslint]

Found 4 issues across 1 rule.

[KrishnaShuk]

How it currently works:

1. Selecting Subjects: When a user searches for subjects, they can now highlight and select multiple items directly from the search results.
2. The Toolbar: Once multiple subjects are selected, the librarian toolbar will pop up at the bottom of the screen with a new "Merge Subjects..." button.
3. The Merge Form: Clicking that button takes the user to a dedicated merge page. Here, they can review the selected subjects, choose which one should be the primary (canonical) subject, and leave an optional comment.
4. Queue Integration: Submitting the form writes a new "Pending" request into our community edits system safely identifying it as a subject merge.
5. Dashboard Updates: Reviewers can now see these pending requests on the main /merges dashboard. We've also added a new "Type" dropdown to the dashboard so maintainers can cleanly filter the list between Work, Author, and Subject requests.

Technical Details:

Frontend: search/subjects.html was updated to surface data-subject-id. SelectionManager.js was given a new regex hook (^/search/subjects$) that recognizes this type and builds the /subjects/merge?records=... URL.

Form Route: The new merge_subjects class in subjects.py handles the page rendering safely by normalizing the prefixes (e.g. person:tolkien) and fetching the latest display data.

Database Insertion: The POST request from the form passes the IDs through process_merge_request, inserting a record into community_edits_queue mapped to our new SUBJECT_MERGE type constant.

Dashboard Filtering: edits.py computes the query parameters for filtering Works/Authors/Subjects in the backend, resolving web.py's strict template limits by passing the toggles down cleanly via the context dictionary into table_header.html.

What is NOT included yet:
This branch does not currently execute the actual database changes yet.

[accesslint]

Found 4 issues across 1 rule.

[accesslint]

Best Practice: Page has multiple banner landmarks.

Page should not have more than one banner landmark.

Details

The banner landmark (typically <header>) identifies site-oriented content like logos and search. Only one top-level banner is allowed per page. If you need multiple headers, nest them inside sectioning elements (article, section, aside) where they become scoped headers rather than page-level banners.

[mekarpeles]

@jimchamp suggests:

It may be helpful to know which works are affected (instead of a count).  It's probably not feasible to print all titles, but maybe a small number would help?

It's hard to tell the type of each MR at a glance.  It may seem to a reviewer that they are reviewing a work merge, only to be taken to the merge subject view.

[KrishnaShuk]

@mekarpeles

1. It is good idea to show some work titles on the merging page. In your opinion how we could showcase the titles without cluttering up the UI?

2. A badge/tag could be added to each MR which would visually help to distinguish between the Work, Author, and Subject requests.