## Problem to solve Currently, the `prevent_secrets` parameter value is automatically filtered out in GitLab logs because it contains the word "secret". This filtering is controlled by the parameter filtering configuration in `config/application.rb`. The relevant code that causes this filtering is here: https://gitlab.com/gitlab-org/gitlab/-/blob/08d081ca8e665fe644a00d0054fdede69869290a/config/application.rb#L117 When the `prevent_secrets` parameter is logged (for example, in push rule updates), its value appears as `"[FILTERED]"` instead of showing the actual boolean value (`true`/`false` or `1`/`0`). ## Intended users - GitLab administrators who need to audit push rule changes - Users monitoring security-related configuration changes ## User experience goal When reviewing logs for push rule updates, administrators should be able to see the actual value of the `prevent_secrets` setting to understand what changes were made. ## Proposal Modify the parameter filtering configuration to exclude `prevent_secrets` from being filtered, since this parameter name refers to a feature setting rather than containing actual secret data. ## What does success look like, and how can we measure that? Success would be measured by: - The `prevent_secrets` parameter value appearing as `true`/`false` or `1`/`0` in logs instead of `"[FILTERED]"` - No regression in filtering of actual secret parameters - Improved auditability of push rule configuration changes ## What is the type of buyer? This affects all GitLab instances where push rules are used and administrators need to audit configuration changes. ## Links / references - Current filtering implementation: https://gitlab.com/gitlab-org/gitlab/-/blob/08d081ca8e665fe644a00d0054fdede69869290a/config/application.rb#L117 - Related to push rules functionality and audit logging