🧪 Developer Tests: Change Management

Part of Developer Tests.

---

tests/change-risk-policy.php

What it tests

Change risk policies (#246): that a change is always rated, validated and kept on the scale it was rated under, and that introducing a new scale never changes how an existing change reads. Internals: Change risk policies - Developer Guide.

How it works

• Part 1 - no database (23 checks). The built-in 5 × 5 gives exactly the old bands in all 25 cells; a policy's result comes from its matrix, not from multiplying (on the test's 4 × 4, 1 × 4 = hoch); ratings out of range, fractional or blank; and every refusal ChangeRiskPolicy::normalise() makes, each paired with the valid policy being accepted.
• Part 2 - a throwaway database (23 checks). Through ChangesService: a change rated on the built-in, then a 4 × 4 policy saved; the old change keeps 5/5/25/Critical and its approval fingerprint; new changes are rated on the 4 × 4; an unchanged save leaves an old change alone; one rating is refused, two re-assess it with an audit row; risk_reassess with the same numbers changes the fingerprint; a template rated on the built-in is neither copied nor pre-authorised on the 4 × 4; a company's own policy wins; Use built-in leaves rated changes on their version.

Part 2 changes the install's risk policy while it runs, so it refuses any database but the one named in FREEITSM_TEST_DATABASE. Its finally deletes its ZZ risk changes, its template and the versions it made, and puts the policy row back as it was.

Run it

php tests/change-risk-policy.php
FREEITSM_TEST_DATABASE=freeitsm_prtest php tests/change-risk-policy.php

Run Part 2 from the test install's directory, so config.php points at the throwaway database. It needs Database Verification run there first, or it skips.

  PASS  a policy result comes from its matrix: 1 x 4 = 4 is "hoch", not the low band a score of 4 would give
  ...
46 passed, 0 failed

If it fails

• "the built-in matrix gives exactly the old bands" - somebody changed ChangeRiskPolicy::builtin(). Every change ever rated on the built-in would read differently; put it back.
• "its approval fingerprint is unchanged" - changeApprovalMaterialValues() is adding the policy version for built-in changes. Every existing approval would read as out of date. See the TRAP in includes/changes/approvals.php.
• "saving an older change with its ratings unchanged leaves them on the built-in" - the untouched-stays-put rule in updateChange() is broken, and every edit of an old change would re-read its numbers on the new scale.
• SKIP - set FREEITSM_TEST_DATABASE, or run Database Verification on that database.