How to have a field required in the model, but not required at create/update?

[jsardev]

Example: a carts collection with items and subtotal fields. I'd like the subtotal field to be required in the model (so that I can be sure that all the saved carts have this property) but not required on create/update as it should be computed on beforeChange hook.

The result should be subtotal: number as the field type when I fetch it, but subtotal: number | null | undefined on create/update.

I was thinking about a virtual field - but that would add unnecessary computing on each read, so it would be better to compute this at save time.

Any ideas what could i do in this situation?

[MurzNN]

I achieved this in GraphQL by setting the admin condition as true, like this:

    {
      name: 'title',
      type: 'text',
      required: true,
      admin: {
        condition: () => true, // Triggers GraphQL nullability automatically
      },
    },

And then, just fill the title in the beforeChange hook - it works well for my case! So, try the same way, maybe it will work for the REST API too.

[zubricks]

I have tackled this in a few personal projects actually! Another approach would be to not use required: true on the field at all — just use a beforeChange hook to always compute and set subtotal. Since the hook runs before every create and update, the value will always be present in the DB in practice, without enforcing it at the validation layer.

{
  name: 'subtotal',
  type: 'number',
  hooks: {
    beforeChange: [
      ({ siblingData }) => {
        return siblingData.items?.reduce((sum, item) => sum + item.price, 0) ?? 0
      }
    ]
  },
  admin: {
    readOnly: true, // prevents users from submitting a value manually
  }
}

admin.readOnly stops the field from being submitted via the Admin UI. The beforeChange hook guarantees the value is always computed server-side regardless of what's in the request.

@MurzNN suggestion of using admin.condition works too but is really a UI-only solve — it hides the field from the form but doesn't prevent it from being submitted via the API.

[jsardev]

@zubricks I think I wasn't clear with the description - the issue here is that the types for this field (when you fetch it e.g. via Local API) is subtotal: number | null | undefined, where I'd like it to be subtotal: number

[MurzNN]

@zubricks, thanks, your option works too for the admin panel, but still keeps the field as required in the GraphQL schema.

So, a proper solution to mark the field as required (to not have null in the type) is still really wanted 😞

[zubricks]

I think you could use typescriptSchema on the field, which lets you override the generated type independently of validation behavior:

{
  name: 'subtotal',
  type: 'number',
  // no required: true — no validation error on create/update
  typescriptSchema: [() => ({ type: 'number' })], // generated type = number (non-nullable)
  hooks: {
    beforeChange: [({ value, data }) => computeSubtotal(data)],
  },
  admin: {
    readOnly: true,
  },
}

which should provide:

• no validation error on create/update
• generated type of number when reading (not number | null | undefined)
• value always computed server-side

[MurzNN]

Thanks, I tried this, but it doesn't resolve the issue - with admin.readOnly == true the subtotal field is still marked as required in the GraphQL schema.

But condition: () => true works well!

Maybe this bug is only on the GraphQL side, but I need to fix it exactly in the GraphQL ;)

[MurzNN]

Reported a bug with reproduction steps: #16797

[MurzNN]

Also, as I see, the virtual field works too! If we do not delete the value in the beforeChange hook, it is stored in the database, so it works well without hooks.
But, it still does not resolve the GraphQL issue, even if the required field is marked as virtual, it stays as required in the GraphQL input, making it impossible to create items without specifying the value for this field.

[MurzNN]

Seems like this is a bug in Payload, so reported it here: #16112

[MurzNN]

Seems the root cause is even deeper, so I (and AI 😏) made some investigations and reported an issue here #17203