Skip to content

fix: use getter method for bot protection level check#4297

Open
jlledom wants to merge 2 commits intomasterfrom
fix-security-screen-master-portal
Open

fix: use getter method for bot protection level check#4297
jlledom wants to merge 2 commits intomasterfrom
fix-security-screen-master-portal

Conversation

@jlledom
Copy link
Copy Markdown
Contributor

@jlledom jlledom commented May 8, 2026

What this PR does / why we need it:

In the Captcha radio button, the values we expect are either none or captcha. However, we got a lot of old records in SaaS which value in the column is empty or NULL.

Instead of backfilling, I created a small migration code in the settings getter:

# To avoid a dangerous DB migration, we allow empty values in the column and assume empty means `:none`
def admin_bot_protection_level
super&.to_sym || :none
end

In the Permissions Policy PR (#4264) we migrated the form to Patternfly, and in the process we started to call settings[field] directly, which bypasses the getter.

Which issue(s) this PR fixes

No Jira issue

Verification steps

  1. Set the admin_bot_protection_level column to NULL in the settings table, for a provider, no need for it to be master.
  2. Go to Account Settings -> Integrate -> Security
  3. Before the patch, it crashes; after the patch, it loads fine.

settings[field] reads the raw DB column value, bypassing the
custom getter that handles nil values. For accounts where
admin_bot_protection_level was never set (e.g. master), the
column is nil, causing `nil.to_sym` to raise NoMethodError.

Using public_send(field) calls the proper getter which returns
:none for nil values and normalizes :auto to :captcha.

Co-Authored-By: Claude <noreply@anthropic.com>
@jlledom jlledom self-assigned this May 8, 2026
akostadinov
akostadinov previously approved these changes May 8, 2026
@mayorova
Copy link
Copy Markdown
Contributor

mayorova commented May 8, 2026

Good, but how about a small test for this one? Just to make sure we don't hit this regression again.

Ensures the security settings page renders when
admin_bot_protection_level is nil in the database, which is
the scenario that caused a NoMethodError on master portal.

Co-Authored-By: Claude <noreply@anthropic.com>
@jlledom
Copy link
Copy Markdown
Contributor Author

jlledom commented May 8, 2026

Good, but how about a small test for this one? Just to make sure we don't hit this regression again.

Here: da7e27f

@qltysh
Copy link
Copy Markdown

qltysh Bot commented May 8, 2026

❌ 1 blocking issue (1 total)

Tool Category Rule Count
rubocop Lint Avoid using update\_column because it skips validations. 1

test 'edit with nil admin_bot_protection_level' do
@provider.settings.update_column(:admin_bot_protection_level, nil)
get edit_provider_admin_security_path
assert_response :success
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
assert_response :success
assert_response :success
assert_xpath '//input[@type="radio"][@name="settings[admin_bot_protection_level]"][@value="none"][@checked]'

We could potentially add this assertion, to make it clear, what's expected when the value is nil.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants