https://gitlab.com/gitlab-org/gitlab/-/merge_requests/155661+ added a new rubocop as part of https://gitlab.com/gitlab-org/gitlab/-/issues/466113+. This epic is to organise the issues required to resolve the exceptions created during the introduction of the rubocop. When a file is excluded from the rubocop, violations won't be flagged. Given there are so many violations, we need a concerted effort to bring the number down. ## Proccess - Identify batches of up to 20 files from `.rubocop_todo/rails/strong_params.yml` - _"It's not officially documented but we let housekeeper to fix up to 20 offenses per MR so I'd suggest to do the same and fix top 20 TODO entries."_ - Create an issue to address that batch, and assign it to yourself, give it a milestone, etc. Follow the development process. - Refactor options include: 1. Permit in-line: `params[:foo]` becomes `params.permit(:foo)[:foo]` 2. Create a new private controller method that permits the expected params, e.g. ```diff def create -- render: MyService.new(params[:foo]).execute(value: params[:bar], params: params) ++ render: MyService.new(service_params[:foo]).execute(value: service_params[:bar], params: service_params) ++ def service_params ++ params.permit(:foo, :bar, :something_else_that_is_allowed) ++ end ``` 3. Permit params via an existing controller method. - Controller specs shouldn't need to be updated, but should of course still pass. - Watch our for cases where a non-scaler is expected, as [using `params.permit(...)` won't continue to pass that through](https://api.rubyonrails.org/classes/ActionController/Parameters.html#method-i-permit) (it will be `nil` instead). - For pagination - `params[:page]` and the like - there is a new helper `pagination_params` that should be used. Introduced by https://gitlab.com/gitlab-org/gitlab/-/merge_requests/156108+. https://gitlab.com/gitlab-org/gitlab/-/blob/master/.rubocop_todo/rails/strong_params.yml ### Notes