We’re running into a critical issue with compliance audit reports in the quality-mgmt module. After upgrading to mf-25.4, our audit reports are missing test execution logs entirely. The report template config seems intact, but when we generate compliance reports for the past quarter, all test execution history is blank.
This is blocking our quarterly compliance audit. We’ve verified that test execution data exists in the database and is visible through the standard test-execution module interface. The traceability matrix also shows proper linkage between requirements and tests, but the audit report generation workflow simply skips the execution logs section.
SELECT COUNT(*) FROM test_execution_history
WHERE execution_date >= '2025-07-01'
-- Returns 1,847 records
Has anyone encountered this after the mf-25.4 update? We suspect it might be related to workflow permissions or a flag in the execution history configuration that changed with the upgrade.
This is likely a traceability rebuild issue. After major version upgrades, the traceability matrix needs to be regenerated to update internal references between modules. The quality-mgmt audit reports rely on these cross-module links. Try running a full traceability rebuild from the admin console. It can take several hours for large datasets, but it should restore the execution log visibility in your compliance reports.
Check the workflow permissions on the audit report generation process. In mf-25.4, they introduced stricter permission checks for cross-module data access. The quality-mgmt module might not have sufficient permissions to read from the test_execution_history tables. You need to verify that the audit workflow service account has read access to execution logs, not just the regular test-execution module permissions.
I ran into the same wall after our mf-25.4 upgrade. The execution history flag is buried in the quality-mgmt configuration now. Here’s what worked for us:
<audit-config>
<include-execution-history>true</include-execution-history>
<execution-retention-days>unlimited</execution-retention-days>
<cross-module-permissions enabled="true" />
</audit-config>
You also need to update the report template config to explicitly reference the execution log data source. Go to Admin > Quality Management > Report Templates > [Your Audit Template] and verify the data source mappings include test_execution_history with proper join conditions.
For workflow permissions, grant the QualityAuditService role read access to the TEST_EXECUTION schema. After making these changes, rebuild the traceability matrix one more time to ensure all cross-references are updated.
The key issue is that mf-25.4 separated execution history into its own permission domain for security compliance. The upgrade doesn’t automatically migrate these permissions, so you need to explicitly configure them. Once you set the execution history flag to unlimited retention and fix the permissions, your audit reports should populate correctly.
We also discovered that if you had custom workflow rules on test execution, those need to be reviewed because the permission model change can affect how execution data is captured for audit purposes.
We had this exact issue last month. The problem is that mf-25.4 changed the default behavior for historical data inclusion in quality-mgmt reports. There’s a configuration flag that controls whether execution logs older than 30 days are included in audit reports. This was done for performance reasons, but it breaks compliance workflows. You need to explicitly enable historical execution data in the report settings.
I’ve seen similar behavior in mf-25.3 during our upgrade testing. The issue was related to report template config changes. Check if your audit report template has the execution history flag properly enabled. In mf-25.4, they changed how the quality-mgmt module references test execution data sources. The template might need to be reconfigured to point to the correct execution log tables.