* Add one-click RRDfile repair to Data Source Info mode
The Data Source Info mode already compares the RRDfile against the Cacti
definition and prints the rrdtool tune recommendations (add a missing Data
Source with DS:name:type:heartbeat:min:max, remove an extra one with DEL:name,
and correct the type, heartbeat, minimum and maximum). It did not, however,
offer a way to apply them from the page the way data_debug.php does.
- Add an "Apply Suggested Fixes" link to the "RRDtool Tune Info" box header when
the web server can write the RRDfile; when it cannot, the header falls back to
"Run Fix from Command Line" and the commands remain listed for manual use.
- Add a ds_repair action that runs the same tune recommendations server-side
(gated on data_source_authorized() and on the RRDfile being writable, and
skipping any recommendation carrying control characters), logs each command to
DSDEBUG, then reloads the Data Source so the result is visible. This mirrors
data_debug.php's run_repair / "Apply Suggested Fixes".
- Harden the Info-mode guard so a missing/unreadable RRDfile (rrdtool info
returning false) no longer triggers an array-offset warning.
* Address review: POST-guard ds_repair and harden repair result check
- Route the "Apply Suggested Fixes" action through a CSRF-protected POST: the
link now uses the cactiPostAction handler (href="#", data-url) instead of a
GET navigation, and ds_repair is added to the $bad_actions guard in
include/global.php so a tokenless request fails closed with 405. ds_repair is
added to the curated CSRF action test for regression coverage.
- Use a strict comparison on the rrdtool_execute() result: it can return null
on a failed exec/proxy connection, and null == '' would have reported a failed
repair as "All RRDfile repairs succeeded."
- Refresh the sink inventory baseline for the new header redirects in ds_repair.
* Add request-coverage probe for the ds_repair RRDfile repair handler
The Data Source Info mode repair handler ds_repair() is a POST action that the
page-level e2e suites do not drive (it needs a Data Source whose RRDfile
mismatches its Cacti definition). Add a request-coverage fixture that loads the
handler in isolation via cacti_fixture_source_function(), stubs its I/O
boundaries, and drives every branch (unauthorized, unreadable RRDfile, no RRA,
nothing to tune, not writable, a control-character recommendation that is
skipped, and both tune success and failure). Register it in
run_request_coverage.sh for data_sources.php changes so the changed-line
coverage gate sees the handler exercised.
* Address review: use defined helpers and boolean repair result
- Replace the undefined cacti_has_control_chars() check with a comparison
against rrd_strip_control_chars() (loaded from lib/rrd.php) to skip any
tune recommendation that carries control characters.
- Execute each tune with RRDTOOL_OUTPUT_BOOLEAN and treat a strict true as
success so proxy storage (which returns the raw 'OK u:...' status under
RRDTOOL_OUTPUT_RETURN_STDERR) is not misreported as a failure.
- Add the new translatable strings to locales/po/cacti.pot and reuse the
existing failure msgid.
- Update the request-coverage fixture to the new boundary contract.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
