ref(forms): migrate projectFiltersSettings to scraps form system

[TkDodo]

Migrates the project inbound filters settings page from the legacy form system (Form, JsonForm, FormField, FieldFromConfig) to the new scraps form system (AutoSaveForm, useScrapsForm, FieldGroup).

Standard filter toggles & legacy browser filter

Each filter toggle (browser-extensions, localhost, web-crawlers, etc.) is now an AutoSaveForm with field.Switch. The legacy browser filter uses AutoSaveForm with a string[] field value and a custom field.Base render for the browser grid UI. Both share mutation options via a getFilterMutationOptions factory. Optimistic updates go through the filter list query cache instead of local useState, so AutoSaveForm's reset-after-save works correctly across rapid toggles.

Project-level boolean filters

Hydration errors and ChunkLoadError toggles use AutoSaveForm backed by the detailed project query cache. Optimistic updates write to both the query cache and ProjectsStore to keep the sidebar and other consumers in sync.

Custom filter textareas

The saveOnBlur: false textarea fields (IP addresses, releases, error messages, etc.) are unified into a single useScrapsForm with explicit Save/Cancel buttons, replacing the old JsonForm + inboundFilters.tsx config. inboundFilters.tsx is deleted since it was only imported here.

FormSearch & field registry

Wraps the migrated forms with FormSearch for settings search indexing and regenerates generatedFieldRegistry.ts.

Refs DE-985

[linear-code]

DE-985

[TkDodo]

bugbot run

[github-actions]

📊 Type Coverage Diff

Metric	Before	After	Delta
Coverage	93.60%	93.60%	±0%
Typed	135,623	135,660	🟢 +37
Untyped	9,281	9,271	🟢 -10

🔍 2 new type safety issues introduced

Type assertions (as) (2 new)

File	Line	Detail
static/app/views/settings/project/projectFilters/projectFiltersSettings.tsx	592	as StandardFilterId — filter.id as StandardFilterId
static/app/views/settings/project/projectFilters/projectFiltersSettings.tsx	783	as keyof typeof filterDescriptions — filter.id as keyof typeof filterDescriptions

This is informational only and does not block the PR.

[priscilawebdev]

I like that we show this info only 1x now, but shouldn't it take the whole available horizontal space?

[priscilawebdev]

We should remove the spacing around this

[priscilawebdev]

Since we now only show one piece of information at the bottom, does it make sense to update the copy as well? Users might wonder which filter it refers to.

[priscilawebdev]

This is flickering a bit

Screen.Recording.2026-05-20.at.12.29.26.mov

[TkDodo]

I like that we show this info only 1x now, but shouldn't it take the whole available horizontal space?

I’ve done this the same way as we have it in Teams settings:

We should remove the spacing around this

It’s consistent with other messages:

Since we now only show one piece of information at the bottom, does it make sense to update the copy as well? Users might wonder which filter it refers to.

I don’t understand what you mean with “update the copy as well”. Please elaborate what you think should be done differently.

This is flickering a bit

Yeah it’s flickering because the toggles disable while the mutation is in-flight but the mutation is very fast here.

sentry/static/app/components/core/form/field/baseField.tsx

Line 83 in 8279199

const isDisabledByAutoSave = autoSaveContext?.status === 'pending';

We could change it for this instance but I’d like to avoid race conditions because users click multiple toggles fast.

since you are touching this file, could you please add the t() around this string

done: e0c5b5a

also since we are touching this file, shouldn't we remove the _features?

good point, not sure what they were there for in the first place: e471789, 732dc3d

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit dd29cb3. Configure here.}

[priscilawebdev]

Thanks applying my feedback.

Regarding the bluish/purplish alert at the bottom: you mentioned it should align with what we render when changing an org slug, but in the org slug flow, the alert appears above the “Cancel” and “Save” buttons and spans the full available width. Shouldn’t we keep this consistent here as well, even if the copy is shorter?

[priscilawebdev]

About the copy: previously, the "Changing this filter will apply to all new events." message was rendered directly below the field being changed, so the context was clear. Now, it’s ambiguous whether it refers to A, B, C, D, or E (see screenshot). It’s a minor nit, but I’d probably update the wording to something more general to avoid confusion.

A few suggestions:

"Changes will only apply to new events."
"Changes to these filters will only apply to new events."

[priscilawebdev]

I noticed that when the user doesn’t have access and the form is disabled, we don’t render the "Cancel" and "Save" buttons. But shouldn’t we still render them in a disabled state?

Other already-migrated forms in Settings do show those buttons, even when disabled, such as in Dynamic Sampling:

[priscilawebdev]

I noticed that when the user doesn’t have access and the form is disabled, we don’t render the "Cancel" and "Save" buttons. But shouldn’t we still render them in a disabled state?

Other already-migrated forms in Settings do show those buttons, even when disabled, such as in Dynamic Sampling:

never mind. in production, we only show the save/cancel buttons if the form is dirty:

[TkDodo]

but in the org slug flow, the alert appears above the “Cancel” and “Save” buttons and spans the full available width.

the org slug flow was probably migrated 1:1 from the old flow. I think we’ve agreed that showing cancel/save buttons after typing something in is not the flow we want. Either fields auto-save, or they have a consistent save/cancel button shown with a message next to them. We can flex the message to take the full width but right now, messages next to save/cancel don’t have that. Happy to streamline in a follow-up.

Other already-migrated forms in Settings do show those buttons, even when disabled, such as in Dynamic Sampling

Hmm we already have a banner at the top saying “These settings can only be edited by users with the organization-level owner, manager, or team-level admin roles.” so adding another disabled button doesn’t really help here I believe

never mind. in production, we only show the save/cancel buttons if the form is dirty:

yeah I changed UX a little bit here because again, those save/cancel buttons popping in per row is not what we want.

[priscilawebdev]

🙌