Problem
When an object in amp.yaml declares optionalFieldsAuto: all (and no explicit optionalFields:, no requiredFields, no mapToName, no field mappings), the InstallWizard lands on the empty Fields sub-page with a message that nothing needs configuring — even though the user should be able to pick from auto-discovered customer fields on the Additional fields sub-page.
Repro
amp.yaml with an object like:
```yaml
- objectName: opportunity
destination: testWebhook
schedule: "*/10 * * * *"
optionalFieldsAuto: all
```
Wizard shows the empty Fields page instead of the Additional fields picker.
Root cause
src/components/InstallWizard/steps/configure-objects/subPageUtils.ts:63-65 decides whether to add the `additional` sub-page using:
```ts
const hasOptionalFields = (obj.getOptionalFields("no-mappings")?.length ?? 0) > 0;
```
`getOptionalFields` (in `src/headless/manifest/useManifest.ts`) reads from `object.optionalFields` — the explicit YAML list. Auto-discovered fields from `optionalFieldsAuto: all` live in `object.allFieldsMetadata` (surfaced via `getCustomerFieldsForObject(objectName).allFields`) and are not considered.
So with `optionalFieldsAuto: all` and no explicit `optionalFields`, `getSubPages` returns `[]` and falls back to `["fields"]`, producing the empty page.
Suggested fix
In `getSubPages` (and any equivalent check), treat "has auto-discovered customer fields" as also satisfying `hasOptionalFields`:
```ts
const hasOptionalFields =
(obj.getOptionalFields("no-mappings")?.length ?? 0) > 0 ||
Object.keys(manifest.getCustomerFieldsForObject(objectName).allFields ?? {}).length > 0;
```
This way an object with only `optionalFieldsAuto: all` lands on the Additional fields sub-page once provider metadata hydrates, where `AdditionalFieldsContent` already renders the available fields as toggleable checkboxes.
Considerations
- During the loading window (before metadata hydrates), `allFields` is empty — the wizard will still briefly fall back to the empty Fields page. We should confirm whether `useSubPageNavigation` re-evaluates `getInitialSubPage` when metadata arrives, or whether we need an additional effect to re-pick the sub-page on hydration.
- Whether `optionalFieldsAuto` values other than `"all"` (if any exist) should behave the same way.
Related
Follow-up to PR #1598 which fixed the navigation case for objects with only field mappings.
Problem
When an object in
amp.yamldeclaresoptionalFieldsAuto: all(and no explicitoptionalFields:, norequiredFields, nomapToName, no field mappings), the InstallWizard lands on the empty Fields sub-page with a message that nothing needs configuring — even though the user should be able to pick from auto-discovered customer fields on the Additional fields sub-page.Repro
amp.yamlwith an object like:```yaml
destination: testWebhook
schedule: "*/10 * * * *"
optionalFieldsAuto: all
```
Wizard shows the empty Fields page instead of the Additional fields picker.
Root cause
src/components/InstallWizard/steps/configure-objects/subPageUtils.ts:63-65decides whether to add the `additional` sub-page using:```ts
const hasOptionalFields = (obj.getOptionalFields("no-mappings")?.length ?? 0) > 0;
```
`getOptionalFields` (in `src/headless/manifest/useManifest.ts`) reads from `object.optionalFields` — the explicit YAML list. Auto-discovered fields from `optionalFieldsAuto: all` live in `object.allFieldsMetadata` (surfaced via `getCustomerFieldsForObject(objectName).allFields`) and are not considered.
So with `optionalFieldsAuto: all` and no explicit `optionalFields`, `getSubPages` returns `[]` and falls back to `["fields"]`, producing the empty page.
Suggested fix
In `getSubPages` (and any equivalent check), treat "has auto-discovered customer fields" as also satisfying `hasOptionalFields`:
```ts
const hasOptionalFields =
(obj.getOptionalFields("no-mappings")?.length ?? 0) > 0 ||
Object.keys(manifest.getCustomerFieldsForObject(objectName).allFields ?? {}).length > 0;
```
This way an object with only `optionalFieldsAuto: all` lands on the Additional fields sub-page once provider metadata hydrates, where `AdditionalFieldsContent` already renders the available fields as toggleable checkboxes.
Considerations
Related
Follow-up to PR #1598 which fixed the navigation case for objects with only field mappings.