fix(dashboard): treat readonly custom fields as optional in Zod schema

[Ryrahul]

Breaking changes

No breaking changes. This is a purely additive fix — the only behavioral change is that readonly custom fields with nullable: false no longer block form submission. All existing validation behavior for non-readonly fields is unchanged.

Summary

Fixes #5045

When a custom field is configured with both readonly: true and nullable: false, the Dashboard's Zod validation schema treats it as required. But readonly fields can never receive a value from the form:

• The server excludes them from Create*Input / Update*Input GraphQL types
• The Dashboard strips them via removeReadonlyAndLocalizedCustomFields() before submitting
• The input is rendered disabled

The result is an unsatisfiable schema — the form is permanently invalid and the Create/Update button stays disabled.

Fix: A single-condition change in applyCustomFieldModifiers() — readonly fields are now always treated as optional regardless of their nullable setting.

- if (customField.nullable !== false) {
+ if (customField.nullable !== false || customField.readonly) {

Checklist

• I have set a clear title
• My PR is small and contains a single feature
• I have checked my own PR
• I have added or updated test cases
• I have updated the README if needed

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
vendure-storybook	Ready	Preview	Aug 3, 2026 6:03pm

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 89a2cdb6-9cab-4fe8-9782-4318aa0bb1af

📥 Commits

Reviewing files that changed from the base of the PR and between 24147cc and 34e4e11.

📒 Files selected for processing (2)

• packages/dashboard/src/lib/framework/form-engine/form-schema-tools.spec.ts
• packages/dashboard/src/lib/framework/form-engine/form-schema-tools.ts

🚧 Files skipped from review as they are similar to previous changes (2)

• packages/dashboard/src/lib/framework/form-engine/form-schema-tools.spec.ts
• packages/dashboard/src/lib/framework/form-engine/form-schema-tools.ts

---

📝 Walkthrough

Walkthrough

Readonly custom fields now receive optional and nullable schema modifiers when nullable is false. Tests cover null, undefined, missing, empty, and provided readonly values. Regression tests confirm that non-readonly non-nullable fields still reject null and undefined.

Suggested reviewers: michaelbromley

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the change to treat readonly custom fields as optional in Dashboard Zod schemas.
Description check	✅ Passed	The description includes the change summary, linked issue, breaking-change status, rationale, implementation details, and completed checklist items.
Linked Issues check	✅ Passed	The implementation directly resolves issue #5045 and tests preserve required validation for non-readonly non-nullable fields.
Out of Scope Changes check	✅ Passed	The changes are limited to the requested schema fix and focused tests, with no unrelated code changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[HouseinIsProgramming]

Nice one, clean fix, and thanks for adding a test.

One thing before I approve: the test covers the readonly case but not the opposite one. I had a fiddle locally, and if you swap the whole condition for if (true) the spec still passes. So nothing's actually guarding the non-nullable behaviour any more.

Worth adding a case where a plain nullable: false field (no readonly) still gets rejected.