fix(cache): add triggering user to cache flush log messages (#36830)

[dsilvam]

Fixes #36830

Proposed Changes

• CacheResource — the five flush endpoints (flushAll, flushRegion, flushGroup, flushObject, deleteMenuCache) built an InitDataObject via WebResource.InitBuilder purely for its auth side effect and discarded the return value, so the authenticated User never reached the log line. They now capture the user and include user.getUserId(), matching the pattern already used throughout MaintenanceResource.
• Promoted four flush logs from debug to info — flushAll, flushGroup, flushObject and deleteMenuCache were debug-only, so under default log levels those flushes left no trace at all. Also fixed a latent gap where flushObject logged the group but never the object id.
• ViewCMSMaintenanceAction — the legacy Struts cache branch now resolves the portlet user (null-guarded via _getUser(req), falling back to "unknown"). This is the path the Maintenance tab's Flush Cache button actually posts to (view_cms_maintenance.jsp → submitform('flushCache') → cmd=cache); it is still wired in struts-config.xml and portlet.xml, and emitted the exact un-attributed Flushing All Caches line from the report.
• Registered CacheResourceIntegrationTest in MainSuite3a — the class was not referenced by any suite, so none of its tests ran in CI. Pre-existing gap from when the class was added in maintenance portlet | Implement Cache Management Apis #35190 #35218; all 11 pre-existing tests pass.

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Only the internal userId is logged (e.g. dotcms.org.1), not email or other PII. No auth logic changed: rejectWhenNoUser(true) + requiredBackendUser(true) + requiredPortlet(...) already guarantee a non-null user before the log line in CacheResource, so no extra guard is needed there. The legacy portlet path can return null, so it is explicitly null-guarded. Low-level flush primitives (MaintenanceUtil.flushCache(), CacheMaintenanceHelper, CMSMaintenanceFactory) were deliberately left user-agnostic — they are invoked from cluster events, startup and search-and-replace, which have no triggering user.

Additional Info

openapi.yaml needs no regeneration — no Swagger annotations or method signatures changed.

Verified in a running instance (both legacy branches):

13:28:12.440  INFO  action.ViewCMSMaintenanceAction - User 'dotcms.org.1' is flushing All Caches
13:31:54.880  INFO  action.ViewCMSMaintenanceAction - User 'dotcms.org.1' is flushing Contentlet Cache

Integration tests — Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, including REST-path attribution:

INFO  cache.CacheResource - User 'dotcms.org.1' flushed cache region 'Permission'
INFO  cache.CacheResource - User 'dotcms.org.1' is flushing all caches
INFO  cache.CacheResource - User 'dotcms.org.1' is flushing the menu cache

./mvnw verify -pl :dotcms-integration -Dcoreit.test.skip=false -Dit.test=CacheResourceIntegrationTest

Not addressed here: CMSMaintenanceAjax.flushIndiciesCache() (DWR path, ES index cache) has the identical gap, but fixing it requires changing validateUser() from boolean to User, touching ~15 unrelated call sites in that class.

🤖 Generated with Claude Code

[claude]

Claude finished @dsilvam's task in 37s —— View job

---

I'll analyze this and get back to you.