Skip to content

feat(next): support document view conditions #12698

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

jessrynkar
Copy link
Member

@jessrynkar jessrynkar commented Jun 5, 2025

Introduces the ability to conditionally render document views. This way you can restrict access to entire views based on certain criteria, such as requesting user or data.

For example, you might want to limit access the /:id/api route to only certain roles.

To do this, use the new condition property in your edit view's config:

import type { CollectionConfig } from 'payload'

export const MyCollectionConfig: CollectionConfig = {
  // ...
  admin: {
    components: {
      views: {
        edit: {
          api: {
            condition: ({ req } ) => Boolean(req.user.roles.includes("admin"))
          }
        }
      }
    }
  }
}

@jessrynkar jessrynkar changed the title feat(ui): adds condition property to all document views feat(next): adds condition property to all document views Jun 6, 2025
jacobsfletch
jacobsfletch previously approved these changes Jun 18, 2025
@jacobsfletch jacobsfletch changed the title feat(next): adds condition property to all document views feat(next): support document view conditions Jun 25, 2025
Copy link
Member

@jacobsfletch jacobsfletch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good—and now that I think about it, we can also deprecate the hideAPIURL property at this point!

We used to render a link to the API endpoint directly on the edit view, but now that it's been given a dedicated page, view conditions should be used to control this instead. I don't think it makes a lot of sense to continue using this property.

Copy link
Member

@jacobsfletch jacobsfletch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It just dawned on me that we might want to control default views on a different property. This will be more future proof, as these features may not use views forever. For example Live Preview is actively being mounted to the /:id route. Let's talk about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants