Refactor static utility usages (FileUtility, DateUtility, …) to avoid StaticAccess issues #682
Description
Summary
Static usages of utility helper classes (for example FileUtility::getFileExtension() or DateUtility::convert()) trigger Codacy’s StaticAccess rule and cause new warnings to fail the static analysis check when introduced in new code.
This issue proposes a gradual refactor of existing static usages of these helpers so that future changes do not run into these checks and the codebase becomes easier to test and maintain.
Background
While working on PR #681, I initially added a static call to FileUtility::getFileExtension() inside Attachments::createFromUpload(). Codacy reported this as a new StaticAccess issue and caused the PR to fail its static analysis check.
During this work I noticed that static FileUtility calls already exist in multiple places across the codebase and are currently accepted as part of the Codacy baseline, but any new occurrences make the check fail. The same pattern exists for other helpers such as DateUtility, which are also used statically in many places but cannot be used in new code without triggering additional StaticAccess warnings.
Problem
The current pattern of using utility helpers like FileUtility or DateUtility statically couples application code tightly to these classes and makes it harder to test or to change behaviour in a controlled way. At the same time, Codacy’s configuration prevents adding new StaticAccess occurrences, which means contributors can easily run into failing checks when following the existing pattern they see in the code. This creates friction for new contributions and makes it unclear which style should be used going forward.