ref: migrate security and privacy to new form system

[TkDodo]

note: there are more forms hidden behind “Advanced Data Scrubbing” modal (add / edit), I will do them in a separate PR.

[linear]

DE-942 Migrate security & privacy

[JonasBa]

Once we are done with the migration, I would like to do a pass on the structure of these, there's a lot to cleanup 😓

[cursor]

Legacy storeCrashReports values lose formatted display

Low Severity

The old code included a placeholder hack specifically for organizations that have a legacy storeCrashReports value not present in the standard options list (e.g., a value like 3 instead of 0, 1, 5, 10, 20, 50, 100, -1). The old placeholder: ({value}) => formatStoreCrashReports(value) ensured these non-standard values displayed a human-readable label like "3 per issue." The new field.Select doesn't include this fallback, so organizations with legacy values will see either a blank select or a default placeholder instead of the formatted value.

 

[sentry]

Bug: The form in ScrubbingConfigurationFieldGroup doesn't re-initialize when organization data changes, causing dirty checks and reset functionality to use stale initialSensitiveFields and initialSafeFields values.
_{Severity: MEDIUM}

Suggested Fix

Use a useEffect hook to explicitly reset the form's state whenever the organization data changes. The effect should have organization.safeFields and organization.sensitiveFields in its dependency array and call a form reset method with the new initial values.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: static/app/views/settings/organizationSecurityAndPrivacy/index.tsx#L400-L401

Potential issue: The `ScrubbingConfigurationFieldGroup` component recalculates
`initialSensitiveFields` and `initialSafeFields` on every render based on updated
organization data. However, the `useScrapsForm` hook does not update its internal state
with new `defaultValues` after its initial render. When another field saves and triggers
a re-render with new organization data, the form's dirty-check logic compares the user's
current input against the newly calculated initial values, not the ones present when
editing began. This leads to incorrect "unsaved changes" alerts and causes the "Cancel"
button to reset the form to the wrong state.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Registry formId mismatches actual form formId

Low Severity

The formId in the scrubbing configuration form is 'organization-settings-security-and-privacy' (with -settings-), but the auto-generated generatedFieldRegistry.ts derives formId: 'organization-security-and-privacy' from the directory name. This mismatch means the registry keys for sensitiveFields and safeFields are inconsistent with the actual form's identity.

Additional Locations (1)

• static/app/components/core/form/generatedFieldRegistry.ts#L222-L240