Just a note here is that Decidim currently also ships its own limitation layer for the public attributes that can be used to filter resources through the HTTP requests. There's a couple of words mentioned about that at #10753.

I think this layer becomes unnecessary after the update is done to Ransack 4. Not saying the refactor should be done in this PR alone but just noting it here since it was one issue when doing the Ransack migration.

Just a note here is that Decidim currently also ships its own limitation layer for the public attributes that can be used to filter resources through the HTTP requests. There's a couple of words mentioned about that at #10753.

I think this layer becomes unnecessary after the update is done to Ransack 4. Not saying the refactor should be done in this PR alone but just noting it here since it was one issue when doing the Ransack migration.

To be honest, the layer added by #8748 , should be complementary. For instance in admin we filter the user by various fields that we may not want to be injectable in general search. I will investigate further next week.

The work in this PR is done to facilitate the rails 7.1 upgrade.

To be honest, the layer added by #8748 , should be complementary. For instance in admin we filter the user by various fields that we may not want to be injectable in general search. I will investigate further next week.

For such cases, you can do the checks over the auth_object provided to the ransackable_n methods, see e.g.

The layer was actually already there prior to #8748 but the implementation was changed to work better with Ransack. I would see that when the security defaults are changed, that layer probably becomes unnecessary. Although, I may not know all the details but typically less code is better.

The work in this PR is done to facilitate the rails 7.1 upgrade.

Yes, I know. I was just pointing this out as I saw this PR (and related to that). As said, that is another issue and just wanted to point it out because of related development.