8 Commits

Author	SHA1	Message	Date
T. R. Bernstein	4a5f01a78f	chore: Update code to new repo	2025-10-08 23:27:45 +02:00
Jessica Rynkar	1845669e68	fix(ui): updates auth fields UI to reflect access control (#12745) ... ### What? Reflects any access control restrictions applied to Auth fields in the UI. I.e. if `email` has `update: () => false` the field should be displayed as read-only. ### Why? Currently any access control that is applied to auth fields is functional but is not matched within the UI. For example: - `password` that does not have read access will not return data, but the field will still be shown when it should be hidden - `email` that does not have update access, updating the field and saving the doc will **not** update the data, but it should be displayed as read-only so nothing can be filled out and the updating restriction is made clear ### How? Passes field permissions through to the Auth fields UI and adds docs with instructions on how to override auth field access. #### Testing Use `access-control` test suite and `auth` collection. Tests added to `access-control` e2e. Fixes #11569	2025-06-25 14:55:07 +01:00
Jarrod Flesch	6939a835ca	fix: beforeValidate deleting value when access returns false (#11549) ... ### What? Regression caused by https://github.com/payloadcms/payload/pull/11433 If a beforeChange hook was checking for a missing or undefined `value` in order to change the value before inserting into the database, data could be lost. ### Why? In #11433 the logic for setting the fallback field value was moved above the logic that cleared the value when access control returned false. ### How? This change ensures that the fallback value is passed into the beforeValidate function _and_ still available with the fallback value on siblingData if access control returns false. Fixes https://github.com/payloadcms/payload/issues/11543	2025-03-05 13:34:08 -05:00
Alessio Gravili	c67291d538	fix(ui): invalid permissions passed to group and named tab sub-fields (#9366) ... Fixes https://github.com/payloadcms/payload/issues/9363 This fixes the following issues that caused fields to be either hidden, or incorrectly set to readOnly in certain configurations: - In some cases, permissions were sanitized incorrectly. This PR rewrites the sanitizePermissions function and adds new unit tests - after a document save, the client was receiving unsanitized permissions. Moving the sanitization logic to the endpoint fixes this - Various incorrect handling of permissions in our form state endpoints / RenderFields	2024-11-20 13:03:35 -07:00
James Mikrut	131d1be8fc	fix(ui): lexical was incorrectly set to readonly in blocks (#9237) ... Fixes a bug introduced in `beta-131` that rendered Lexical fields as read-only if they were within a block.	2024-11-15 22:47:26 +00:00
Alessio Gravili	90b7b20699	feat!: beta-next (#7620) ... This PR makes three major changes to the codebase: 1. [Component Paths](#component-paths) Instead of importing custom components into your config directly, they are now defined as file paths and rendered only when needed. That way the Payload config will be significantly more lightweight, and ensures that the Payload config is 100% server-only and Node-safe. Related discussion: https://github.com/payloadcms/payload/discussions/6938 2. [Client Config](#client-config) Deprecates the component map by merging its logic into the client config. The main goal of this change is for performance and simplification. There was no need to deeply iterate over the Payload config twice, once for the component map, and another for the client config. Instead, we can do everything in the client config one time. This has also dramatically simplified the client side prop drilling through the UI library. Now, all components can share the same client config which matches the exact shape of their Payload config (with the exception of non-serializable props and mapped custom components). 3. [Custom client component are no longer server-rendered](#custom-client-components-are-no-longer-server-rendered) Previously, custom components would be server-rendered, no matter if they are server or client components. Now, only server components are rendered on the server. Client components are automatically detected, and simply get passed through as `MappedComponent` to be rendered fully client-side. ## Component Paths Instead of importing custom components into your config directly, they are now defined as file paths and rendered only when needed. That way the Payload config will be significantly more lightweight, and ensures that the Payload config is 100% server-only and Node-safe. Related discussion: https://github.com/payloadcms/payload/discussions/6938 In order to reference any custom components in the Payload config, you now have to specify a string path to the component instead of importing it. Old: ```ts import { MyComponent2} from './MyComponent2.js' admin: { components: { Label: MyComponent2 }, }, ``` New: ```ts admin: { components: { Label: '/collections/Posts/MyComponent2.js#MyComponent2', // <= has to be a relative path based on a baseDir configured in the Payload config - NOT relative based on the importing file }, }, ``` ### Local API within Next.js routes Previously, if you used the Payload Local API within Next.js pages, all the client-side modules are being added to the bundle for that specific page, even if you only need server-side functionality. This `/test` route, which uses the Payload local API, was previously 460 kb. It is now down to 91 kb and does not bundle the Payload client-side admin panel anymore. All tests done [here](https://github.com/payloadcms/payload-3.0-demo/tree/feat/path-test) with beta.67/PR, db-mongodb and default richtext-lexical: **dev /admin before:**  **dev /admin after:**  --- **dev /test before:**  **dev /test after:**  --- **build before:**  **build after::**  ### Usage of the Payload Local API / config outside of Next.js This will make it a lot easier to use the Payload config / local API in other, server-side contexts. Previously, you might encounter errors due to client files (like .scss files) not being allowed to be imported. ## Client Config Deprecates the component map by merging its logic into the client config. The main goal of this change is for performance and simplification. There was no need to deeply iterate over the Payload config twice, once for the component map, and another for the client config. Instead, we can do everything in the client config one time. This has also dramatically simplified the client side prop drilling through the UI library. Now, all components can share the same client config which matches the exact shape of their Payload config (with the exception of non-serializable props and mapped custom components). This is breaking change. The `useComponentMap` hook no longer exists, and most component props have changed (for the better): ```ts const { componentMap } = useComponentMap() // old const { config } = useConfig() // new ``` The `useConfig` hook has also changed in shape, `config` is now a property _within_ the context obj: ```ts const config = useConfig() // old const { config } = useConfig() // new ``` ## Custom Client Components are no longer server rendered Previously, custom components would be server-rendered, no matter if they are server or client components. Now, only server components are rendered on the server. Client components are automatically detected, and simply get passed through as `MappedComponent` to be rendered fully client-side. The benefit of this change: Custom client components can now receive props. Previously, the only way for them to receive dynamic props from a parent client component was to use hooks, e.g. `useFieldProps()`. Now, we do have the option of passing in props to the custom components directly, if they are client components. This will be simpler than having to look for the correct hook. This makes rendering them on the client a little bit more complex, as you now have to check if that component is a server component (=> already has been rendered) or a client component (=> not rendered yet, has to be rendered here). However, this added complexity has been alleviated through the easy-to-use `<RenderMappedComponent />` helper. This helper now also handles rendering arrays of custom components (e.g. beforeList, beforeLogin ...), which actually makes rendering custom components easier in some cases. ## Misc improvements This PR includes misc, breaking changes. For example, we previously allowed unions between components and config object for the same property. E.g. for the custom view property, you were allowed to pass in a custom component or an object with other properties, alongside a custom component. Those union types are now gone. You can now either pass an object, or a component. The previous `{ View: MyViewComponent}` is now `{ View: { Component: MyViewComponent} }` or `{ View: { Default: { Component: MyViewComponent} } }`. This dramatically simplifies the way we read & process those properties, especially in buildComponentMap. We can now simply check for the existence of one specific property, which always has to be a component, instead of running cursed runtime checks on a shared union property which could contain a component, but could also contain functions or objects.   - [x] I have read and understand the [CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md) document in this repository. --------- Co-authored-by: PatrikKozak <patrik@payloadcms.com> Co-authored-by: Paul <paul@payloadcms.com> Co-authored-by: Paul Popus <paul@nouance.io> Co-authored-by: Jacob Fletcher <jacobsfletch@gmail.com> Co-authored-by: James <james@trbl.design>	2024-08-13 12:54:33 -04:00
Alessio Gravili	83fd4c6622	chore: run lint and prettier on entire codebase	2024-07-11 15:27:01 -04:00
Jarrod Flesch	cedd916816	fix: corrects permission access reading for disabling fields (#6815) ... Fixes issues where access control was not properly affecting the read-only setting on fields.	2024-06-17 18:33:45 -04:00