Read-only fields show and are editable when creating new document.

[richardvanbergen]

Bug Report

As discussed in #98 I created a virtual field like so:

{
  label: 'S3 URL',
  name: 's3Url',
  type: 'text',
  admin: {
    readOnly: true,
  },
  hooks: {
    beforeChange: [
      (): undefined => undefined,
    ],
    afterRead: [
      ({ data }): string => {
        return getUrl(String(data.filename))
      }
    ]
  }
}

When editing an existing document, we get a disabled text input with the correct text.

However when creating a new document, we get an empty text area that the user can edit.

Expected Behavior

Ideally, unless there's a reason no to we should not see the read-only field at all until the document is created.

Current Behavior

Shows editable text input.

Steps to Reproduce

1. Create a field on a collection with {admin: {readOnly: true}}.
2. Try to create a new document.

Detailed Description

Payload version: 0.4.4

[jmikrut]

Hey @richardvanbergen ,

This is actually intended behavior that we settled on while designing the readOnly feature.

We thought that in order for a field to be "read", its value must be set in the first place. While a value could be set with hooks or through APIs, given that this command only affects the admin panel, we determined that readOnly should only affect update operations.

To disable your field within the create operation, you can set an access control function on it like below:

{
  label: 'S3 URL',
  name: 's3Url',
  type: 'text',
  admin: {
    readOnly: true,
  },
  access: {
    create: () => false,
  },
  hooks: {
    beforeChange: [
      (): undefined => undefined,
    ],
    afterRead: [
      ({ data }): string => {
        return getUrl(String(data.filename))
      }
    ]
  }
}

I am open to revisiting the readOnly function though. We use it on things like Transactions or Orders, where an admin may need to manually place an order for a customer upfront, and have the ability to create all fields, but then not be able to go back and re-edit.

However, our above use-case could be solved the same way through access control functions. Thoughts?

@denolfe @DanRibbens

[jmikrut]

Update:

Changing readOnly to affect both create and update will only require one line to be removed:

https://github.com/payloadcms/payload/blob/master/src/admin/components/forms/RenderFields/index.tsx#L78

Nice and easy. I'm up for it...

[denolfe]

@richardvanbergen In addition to the above fix, you'll likely want to use a condition to hide the field if it is not populated like this:

admin: {
  readOnly: true,
  condition: (data) => data?.s3Url,
}

[DanRibbens]

I agree, readOnly should be applied consistently.

In a future update we could allow a function call that returns boolean to give devs more control. That complicates the admin UI a little so we can wait on that for now.

[richardvanbergen]

Thanks guys that all makes a lot of sense. I didn't really have a use case for it because we're all about the content editing and less so about transactions.

Sorry about the late reply I kind of forgot I filed this bug report 😆