Modernization of the Requirement Specification Tree move / re-parent flow, which had no screen at all in 1.9.20. The legacy write path was the AJAX endpoint lib/ajax/dragdroprequirementnodes.php (doAction=changeParent / doAction=doReorder), called straight from a drag-and-drop widget. Now a standalone Dashio screen backed by a REST BFF, reachable from the Requirement Specification Viewer toolbar.

• Context card — test project, requirement specification (with its requirement count), spec revision, requirement count and the real Modified by author (the creator of the newest req_specs_revisions row, never a hardcoded admin).
• Specification picker — every spec of the project, doc_id — title (n).
• Reorder table — one row per requirement: document id, title, and Select / Up / Down / To top / To bottom, plus drag-and-drop. Every button acts on its own row. A drag or a button click marks the form dirty (an Unsaved changes chip) — nothing is written until Apply order. Discard changes reloads from the server, Refresh re-reads.
• Move a requirement to another specification — pick a target spec and At the top / At the bottom, confirm in a Bootstrap modal (spec and requirement named in the message), then the screen follows the requirement into its new spec.
• States — read-only banner for view-only users, denied box + disabled writes for 403, not-found box for 404, empty box for a spec with no requirements.

Base api/reqtreereorder/index.php. Session auth + bffSameOriginGuard(); JSON in, JSON out.

Error contract: 401 unauthenticated, 403 no rights / cross-origin, 404 unknown or foreign spec/requirement, 400 bad params (incl. invalid_nodes_order on a duplicate id and no_change when nothing moved), 405 wrong verb, 409 duplicate_doc_id.

init evaluates rights on the requested project before it resolves the node, and only then compares the node's owning project with it. The other order turned the endpoint into a cross-project existence oracle: a user without rights got 404 for a foreign id but 403 for an existing one. move never resolves or writes anything before mgt_modify_req on the owning project has been confirmed.

TestLink adds a node_type_id=8 (requirement version) node on every revision and never removes the previous one, so a plain join returns a revised requirement once per revision (measured: 81, 81, 81, 83, 85 after one revision of 81). The list therefore pins the join to the newest version node (VN.id = (SELECT MAX(VN2.id) …)), while keeping the LEFT JOIN so a requirement with no version node at all still appears (defensive: such a row renders with an empty status/version instead of disappearing from the tree).

Suite 1681 — 45/45 PASS (BFF contract, browser flows, permission paths, i18n, legacy shim, syntax/JSON checks, Event Viewer). Bugs found while testing, each filed with bug:

php tmp/fixtures_1681.php
# -> tproject (prefix TR1), specA (3 requirements), specB (0 requirements)
# -> tr1681norights  (role 3, <no rights>)               -> 403 path
# -> tr1681readonly  (custom role: mgt_view_req only)    -> read-only path

http://localhost:8082/gui/templates/requirements/reqTreeReorder.html?tproject_id=<TP>&req_spec_id=<SPECA> (all fixture users use the password admin).

database::fetchRowsIntoMap() returns null — not an empty array — when a query matches no rows. Any array_keys() / implode() / foreach() on its result must be guarded (#1692). The same "return null for an empty result" contract is the sibling screen api/reqreorder's latest-version pattern; keep the two queries in sync when the schema moves.