The Log Message viewer shows the full, untruncated change log of a requirement specification revision, a requirement version, or a requirement revision. It replaces the two legacy 1.9.20 AJAX readers lib/ajax/getreqspeclog.php and lib/ajax/getreqlog.php with a modern Dashio popup backed by a plain-PHP REST BFF. It is not an ASIDE entry: it is reached from the open the full log affordance on the requirement screens and from legacy deep links.

URL: gui/templates/requirements/logViewer.html?type=<type>&id=<id>&tproject_id=<id> BFF API: api/logviewer/index.php — GET ?action=log&type=<type>&id=<id>&tproject_id=<id> Rights: mgt_view_req on the owning test project (resolved server-side, not taken from the request) Tracking issue: #1652

1. Screen Layout
2. Data Flow and Parity
3. The three object types
4. i18n
5. Permission Path and Error States
6. Legacy Endpoints
7. BFF API Reference
8. Bugs Found and Fixed
9. Files
10. Screenshots

The legacy readers did SELECT log_message FROM <table> WHERE id = <intval> and then echoed the result with nl2br() after stripping a wrapping <p>. The BFF keeps the same normalization but operates on the decoded text, so the payload stays plain text:

1. preg_replace('#</?p\s*>#i', "\n", …) — the legacy <p> wrapper becomes a newline (legacy: stripped / turned into <br>).
2. preg_replace('#<br\s*/?>#i', "\n", …) — remaining line markup becomes a newline.
3. strip_tags() — residual editor markup (fonts, divs, spans) is dropped.
4. html_entity_decode() — the browser used to render the entities in the fragment.
5. Newline and whitespace tidy-up, then trim().

The screen renders the result with .text() (logViewer.html), never .html(). That is the security difference from the legacy endpoint, which echoed the stored blob straight into the DOM.

Titles. Neither req_specs, req_specs_revisions, requirements, testprojects nor req_revisions is a reliable title source in this schema, so:

• a spec revision's title is the name of its nodes_hierarchy node (node_type_id = 6);
• a requirement's title is the name of its nodes_hierarchy node (node_type_id = 7);
• the test project name comes from testproject::getName(), which reads the nodes_hierarchy testproject node (node_type_id = 1).

For the two requirement types the BFF also reads nodes_hierarchy to prove the node really is of the declared type, and joins the owning requirement for its Doc ID, the owning spec's Doc ID, and the owning test project. requirement_spec_version needs no such proof: req_specs_revisions.id is the revision node id by construction.

The screen also accepts the legacy aliases reqspec → requirement_spec_version and req → requirement, and the legacy item_id query parameter, so an old bookmark still lands on the right screen.

24 logv.* keys plus footers.logViewer, defined identically in all 10 locale bundles (en, ro, de, es, fr, it, pt, ru, ja, zh); every bundle is validated with python3 -m json.tool. There are no hardcoded user-visible strings: the type badge, the context-row labels, all six error states and the character counter are translated.

The generic error box switches on the BFF machine code and shows a translated string — the API's English message is a developer string and is never painted into a non-English UI.

logv.testProject was originally translated as "Requirement specification" while the value it labelled was the test project. Corrected in all 10 bundles (#1655).

Authorization is enforced on the project resolved from the database, and the "does this id belong to the project you asked for" check runs before the rights check, so an id from another project answers 404 and never leaks whether it exists. Every SQL value is intval()-guarded, including the tproject_id used in the Location header of the legacy shims.

X-Requested-With / same-origin proof is required for unsafe verbs (the shared CSRF guard answers 403 first); GET is a safe read-only verb and stays available. X-Content-Type-Options: nosniff is sent, and a register_shutdown_function() backstop turns any unexpected fatal into a valid JSON 500 instead of TestLink's raw HTML error page.

lib/ajax/getreqspeclog.php and lib/ajax/getreqlog.php are still live: six legacy Smarty templates build the log tooltip with new Ext.ToolTip({ autoLoad:{ url: … } }), and Ext injects the response body as HTML:

So each endpoint now answers the contract its caller actually has:

• XHR (X-Requested-With, which Ext sets) → an HTML fragment: the same normalization as the BFF, then htmlspecialchars(ENT_QUOTES | ENT_SUBSTITUTE) + nl2br(). Visually the same tooltip, and a log containing <script> renders as visible text instead of executing in the caller's page. An empty log keeps the 1.9.20 empty_log_message hint instead of a blank bubble.
• Plain browser GET (a deep link) → a 302 to the modern screen, which enforces the rights the legacy readers never checked. getreqlog.php reproduces the 1.9.20 node-type auto-detection first: a req_versions row is a requirement version (type=requirement_version), any other requirement node is a revision (type=requirement), so a revision deep link no longer lands on the version screen and its 404. An id that is not a requirement node at all is traced in the Event Viewer.

Authorization on the fragment branch. The live tooltip callers pass item_id only, so scoping by a caller-supplied tproject_id is not enough. Both shims therefore derive the owning test project from the id itself (req_specs.testproject_id, reached through nodes_hierarchy → requirements for the requirement logs) and enforce mgt_view_req on it before emitting anything:

The revision branches also prove the node type in SQL (nodes_hierarchy.node_type_id 10 for a requirement revision, 11 for a spec revision) instead of trusting the shared id space, and the node type is compared numerically (8 / 10), the same way api/logviewer/index.php does, so a renamed or localized node_types.description cannot mis-route a deep link.

An anonymous caller gets TestLink's standard login.php?note=expired&destination=… script, on both branches.

GET api/logviewer/index.php?action=log&type=<type>&id=<id>&tproject_id=<id>

{
  "status": "ok",
  "context": {
    "type": "requirement_version",
    "item_id": 233,
    "testproject_id": 313,
    "object_label": "First requirement",
    "object_id": "REQ-LOGV-1",
    "version_label": "v1 / rev#1",
    "revision": 1,
    "parent_id": 322,
    "parent_doc_id": "RS-LOGV",
    "parent_name": "LOGV"
  },
  "log": {
    "text": "Version 1 of REQ-LOGV-1: initial & final.\nSecond line with markup kept as text.",
    "is_empty": false,
    "raw_length": 97,
    "legacy_note_empty": "empty_log_message"
  }
}

Error payloads always carry status: "error", an English message for developers, and a stable machine code: