21 Commits

Author	SHA1	Message	Date
T. R. Bernstein	4a5f01a78f	chore: Update code to new repo	2025-10-08 23:27:45 +02:00
Jarrod Flesch	72349245ca	test: fix flaky sorting test (#13303) ... Ensures the browser uses fresh data after seeding by refreshing the route and navigating when done.	2025-07-29 03:25:09 +00:00
Jarrod Flesch	fa7d209cc9	fix(ui): incorrect blocks label sizing (#13264) ... Blocks container labels should match the Array and Tab labels. Uses same styling approach as Array labels. ### Before <img width="229" height="260" alt="CleanShot 2025-07-24 at 12 26 38" src="https://github.com/user-attachments/assets/9c4eb7c5-3638-4b47-805b-1206f195f5eb" /> ### After <img width="245" height="259" alt="CleanShot 2025-07-24 at 12 27 00" src="https://github.com/user-attachments/assets/c04933b4-226f-403b-9913-24ba00857aab" />	2025-07-24 19:34:29 +00:00
Jacob Fletcher	bccf6ab16f	feat: group by (#13138) ... Supports grouping documents by specific fields within the list view. For example, imagine having a "posts" collection with a "categories" field. To report on each specific category, you'd traditionally filter for each category, one at a time. This can be quite inefficient, especially with large datasets. Now, you can interact with all categories simultaneously, grouped by distinct values. Here is a simple demonstration: https://github.com/user-attachments/assets/0dcd19d2-e983-47e6-9ea2-cfdd2424d8b5 Enable on any collection by setting the `admin.groupBy` property: ```ts import type { CollectionConfig } from 'payload' const MyCollection: CollectionConfig = { // ... admin: { groupBy: true } } ``` This is currently marked as beta to gather feedback while we reach full stability, and to leave room for API changes and other modifications. Use at your own risk. Note: when using `groupBy`, bulk editing is done group-by-group. In the future we may support cross-group bulk editing. Dependent on #13102 (merged). --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1210774523852467 --------- Co-authored-by: Paul Popus <paul@payloadcms.com>	2025-07-24 14:00:52 -04:00
Jarrod Flesch	8900a38678	fix: uses valid fractional index for test (#12942)	2025-06-26 06:40:18 -04:00
Paul	5368440115	chore: fix jest global teardown incorrectly always returning process exit status 0 (#12907) ... We were running scripts as they were without encompassing our logic in a function for jest's teardown and we were subsequently running `process.exit(0)` which meant that tests didn't correctly return an error status code when they failed in CI. The following tests have been skipped as well: ``` ● postgres vector custom column › should add a vector column and query it ● Sort › Local API › Orderable › should not break with existing base 62 digits ● Sort › Local API › Orderable join › should set order by default ● Sort › Local API › Orderable join › should allow setting the order with the local API ● Sort › Local API › Orderable join › should sort join docs in the correct ``` --------- Co-authored-by: Elliot DeNolf <denolfe@gmail.com> Co-authored-by: Alessio Gravili <alessio@gravili.de>	2025-06-25 17:43:57 -07:00
Sasha	e60db0750a	fix(ui): reordering with a join field inside a group (#12803) ... Fixes https://github.com/payloadcms/payload/issues/12802	2025-06-13 12:31:07 -04:00
Dan Ribbens	37afbe6c04	fix: orderable has incorrect sort results depending on capitalization (#12758) ... ### What? The results when querying orderable collections can be incorrect due to how the underlying database handles sorting when capitalized letters are introduced. ### Why? The original fractional indexing logic uses base 62 characters to maximize the amount of data per character. This optimization saves a few characters of text in the database but fails to return accurate results when mixing uppercase and lowercase characters. ### How? Instead we can use base 36 values instead (0-9,a-z) so that all databases handle the sort consistently without needing to introduce collation or other alternate solutions. Fixes #12397	2025-06-11 09:49:53 -04:00
Alessio Gravili	7c05c775cb	docs: improve jobs autorun docs, adds e2e test (#12196) ... This clarifies that jobs.autoRun only *runs* already-queued jobs. It does not queue the jobs for you. Also adds an e2e test as this functionality had no e2e coverage	2025-06-05 09:19:19 -07:00
Paul	72ab319d37	fix(db-*): ensure consistent sorting even when sorting on non-unique fields or no sort parameters at all (#12447) ... The databases do not keep track of document order internally so when sorting by non-unique fields such as shared `order` number values, the returned order will be random and not consistent. While this issue is far more noticeable on mongo it could also occur in postgres on certain environments. This combined with pagination can lead to the perception of duplicated or inconsistent data. This PR adds a second sort parameter to queries so that we always have a fallback, `-createdAt` will be used by default or `id` if timestamps are disabled.	2025-05-19 12:59:12 -07:00
Germán Jabloñski	2a929cf385	chore: fix all lint errors and add mechanisms to prevent them from appearing again (#12401) ... I think it's easier to review this PR commit by commit, so I'll explain it this way: ## Commits 1. [parallelize eslint script (still showing logs results in serial)](c9ac49c12d): Previously, `--concurrency 1` was added to the script to make the logs more readable. However, turborepo has an option specifically for these use cases: `--log-order=grouped` runs the tasks in parallel but outputs them serially. As a result, the lint script is now significantly faster. 2. [run pnpm lint:fix](9c128c276a) The auto-fix was run, which resolved some eslint errors that were slipped in due to the use of `no-verify`. Most of these were `perfectionist` fixes (property ordering) and the removal of unnecessary assertions. Starting with this PR, this won't happen again in the future, as we'll be verifying the linter in every PR across the entire codebase (see commit 7). 3. [fix eslint non-autofixable errors](700f412a33) All manual errors have been resolved except for the configuration errors addressed in commit 5. Most were React compiler violations, which have been disabled and commented out "TODO" for now. There's also an unused `use no memo` and a couple of `require` errors. 4. [move react-compiler linter to eslint-config package](4f7cb4d63a) To simplify the eslint configuration. My concern was that there would be a performance regression when used in non-react related packages, but none was experienced. This is probably because it only runs on .tsx files. 5. [remove redundant eslint config files and fix allowDefaultProject](a94347995a) The main feature introduced by `typescript-eslint` v8 was `projectService`, which automatically searches each file for the closest `tsconfig`, greatly simplifying configuration in monorepos ([source](https://typescript-eslint.io/blog/announcing-typescript-eslint-v8#project-service)). Once I moved `projectService` to `packages/eslint-config`, all the other configuration files could be easily removed. I confirmed that pnpm lint still works on individual packages. The other important change was that the pending eslint errors from commits 2 and 3 were resolved. That is, some files were giving the error: "[File] was not found by the project service. Consider either including it in the tsconfig.json or including it in allowDefaultProject." Below I copy the explanatory comment I left in the code: ```ts // This is necessary because `tsconfig.base.json` defines `"rootDir": "${configDir}/src"`, // And the following files aren't in src because they aren't transpiled. // This is typescript-eslint's way of adding files that aren't included in tsconfig. // See: https://typescript-eslint.io/troubleshooting/typed-linting/#i-get-errors-telling-me--was-not-found-by-the-project-service-consider-either-including-it-in-the-tsconfigjson-or-including-it-in-allowdefaultproject // The best practice is to have a tsconfig.json that covers ALL files and is used for // typechecking (with noEmit), and a `tsconfig.build.json` that is used for the build // (or alternatively, swc, tsup or tsdown). That's what we should ideally do, in which case // this hardcoded list wouldn't be necessary. Note that these files don't currently go // through ts, only through eslint. ``` 6. [Differentiate errors from warnings in VScode ESLint Rules](5914d2f48d) There's no reason to do that. If an eslint rule isn't an error, it should be disabled or converted to a warning. 7. [Disable skip lint, and lint over the entire repo now that it's faster](e4b28f1360) The GitHub action linted only the files that had changed in the PR. While this seems like a good idea, once exceptions were introduced with [skip lint], they opened the door to propagating more and more errors. Often, the linter was skipped, not because someone introduced new errors, but because they were trying to avoid those that had already crept in, sometimes accidentally introducing new ones. On the other hand, `pnpm lint` now runs in parallel (commit 1), so it's not that slow. Additionally, it runs in parallel with other GitHub actions like e2e tests, which take much longer, so it can't represent a bottleneck in CI. 8. [fix lint in next package](4506595f91) Small fix missing from commit 5 9. [Merge remote-tracking branch 'origin/main' into fix-eslint](563d4909c1) 10. [add again eslint.config.js in payload package](78f6ffcae7) The comment in the code explains it. Basically, after the merge from main, the payload package runs out of memory when linting, probably because it grew in recent PRs. That package will sooner or later collapse for our tooling, so we may have to split it. It's already too big. ## Future Actions - Resolve React compiler violations, as mentioned in commit 3. - Decouple the `tsconfig` used for typechecking and build across the entire monorepo (as explained in point 5) to ensure ts coverage even for files that aren't transpiled (such as scripts). - Remove the few remaining `eslint.config.js`. I had to leave the `richtext-lexical` and `next` ones for now. They could be moved to the root config and scoped to their packages, as we do for example with `templates/vercel-postgres/**`. However, I couldn't get it to work, I don't know why. - Make eslint in the test folder usable. Not only are we not linting `test` in CI, but now the `pnpm eslint .` command is so large that my computer freezes. If each suite were its own package, this would be solved, and dynamic codegen + git hooks to modify tsconfig.base.json wouldn't be necessary ([related](https://github.com/payloadcms/payload/pull/11984)).	2025-05-19 12:36:40 -03:00
Germán Jabloñski	529bfe149e	fix: orderable with groups and tabs requires migration (#12422) ... ⚠️ `orderable` fields will no longer be `required` and `unique`, so your database may prompt you to accept an automatic migration if you're using [this feature](https://payloadcms.com/docs/configuration/collections#config-options). Note that the `orderable` feature is still experimental, so it may still receive breaking changes without a major upgrade or contain bugs. Use it with caution. ___ The `orderable` fields will not have `required` and `unique` constraints at the database schema level, in order to automatically migrate collections that incorporate this property. Now, when a user adds the `orderable` property to a collection or join field, existing documents will have the order field set to undefined. The first time you try to reorder them, the documents will be automatically assigned an initial order, and you will be prompted to refresh the page. We believe this provides a better development experience than having to manually migrate data with a script. Additionally, it fixes a bug that occurred when using `orderable` in conjunction with groups and tabs fields. Closes: - #12129 - #12331 - #12212 --------- Co-authored-by: Dan Ribbens <dan.ribbens@gmail.com>	2025-05-16 22:21:46 +00:00
Sasha	710fe0949b	fix: duplicate with orderable (#12274) ... Previously, duplication with orderable collections worked incorrectly, for example Document 1 is created - `_order: 'a5'` Document 2 is duplicated from 1, - `_order: 'a5 - copy'` (result from 47a1eee765/packages/payload/src/fields/setDefaultBeforeDuplicate.ts (L6)) Now, the `_order` value is re-calculated properly.	2025-04-30 17:28:13 +00:00
Corey Larson	b750ba4509	fix(ui): reflect default sort in join tables (#12084) ... <!-- Thank you for the PR! Please go through the checklist below and make sure you've completed all the steps. Please review the [CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md) document in this repository if you haven't already. The following items will ensure that your PR is handled as smoothly as possible: - PR Title must follow conventional commits format. For example, `feat: my new feature`, `fix(plugin-seo): my fix`. - Minimal description explained as if explained to someone not immediately familiar with the code. - Provide before/after screenshots or code diffs if applicable. - Link any related issues/discussions from GitHub or Discord. - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Fixes # --> ### What? This PR ensures defaultSort is reflected in join tables. ### Why? Currently, default sort is not reflected in the join table state. The data _is_ sorted correctly, but the table state sort is undefined. This is mainly an issue for join fields with `orderable: true` because you can't re-order the table until `order` is the selected sort column. ### How? Added `defaultSort` prop to the `<ListQueryProvider />` in the `<RelationshipTable />` and ensured the default state gets set in `<ListQueryProvider />` when `modifySearchParams` is false. **Before:** <img width="1390" alt="Screenshot 2025-04-11 at 2 33 19 AM" src="https://github.com/user-attachments/assets/4a008d98-d308-4397-a35a-69795e5a6070" /> **After:** <img width="1362" alt="Screenshot 2025-04-11 at 3 04 07 AM" src="https://github.com/user-attachments/assets/4748e354-36e4-451f-83e8-6f84fe58d5b5" /> Fixes #12083 --------- Co-authored-by: Germán Jabloñski <43938777+GermanJablo@users.noreply.github.com>	2025-04-18 07:10:48 -03:00
Dan Ribbens	e90ff72b37	fix: reordering draft documents causes data loss (#12109) ... Re-ordering documents with drafts uses `payload.update()` with `select: { id: true }` and that causes draft versions of those docs to be updated without any data. I've removed the `select` optimization to prevent data loss. Fixes #12097	2025-04-15 12:09:55 -04:00
Germán Jabloñski	d963e6a54c	feat: orderable collections (#11452) ... Closes https://github.com/payloadcms/payload/discussions/1413 ### What? Introduces a new `orderable` boolean property on collections that allows dragging and dropping rows to reorder them: https://github.com/user-attachments/assets/8ee85cf0-add1-48e5-a0a2-f73ad66aa24a ### Why? [One of the most requested features](https://github.com/payloadcms/payload/discussions/1413). Additionally, poorly implemented it can be very costly in terms of performance. This can be especially useful for implementing custom views like kanban. ### How? We are using fractional indexing. In its simplest form, it consists of calculating the order of an item to be inserted as the average of its two adjacent elements. There is [a famous article by David Greenspan](https://observablehq.com/@dgreensp/implementing-fractional-indexing) that solves the problem of running out of keys after several partitions. We are using his algorithm, implemented [in this library](https://github.com/rocicorp/fractional-indexing). This means that if you insert, delete or move documents in the collection, you do not have to modify the order of the rest of the documents, making the operation more performant. --------- Co-authored-by: Dan Ribbens <dan.ribbens@gmail.com>	2025-04-01 14:11:11 -04:00
Jacob Fletcher	998181b986	feat: query presets (#11330) ... Query Presets allow you to save and share filters, columns, and sort orders for your collections. This is useful for reusing common or complex filtering patterns and column configurations across your team. Query Presets are defined on the fly by the users of your app, rather than being hard coded into the Payload Config. Here's a screen recording demonstrating the general workflow as it relates to the list view. Query Presets are not exclusive to the admin panel, however, as they could be useful in a number of other contexts and environments. https://github.com/user-attachments/assets/1fe1155e-ae78-4f59-9138-af352762a1d5 Each Query Preset is saved as a new record in the database under the `payload-query-presets` collection. This will effectively make them CRUDable and allows for an endless number of preset configurations. As you make changes to filters, columns, limit, etc. you can choose to save them as a new record and optionally share them with others. Normal document-level access control will determine who can read, update, and delete these records. Payload provides a set of sensible defaults here, such as "only me", "everyone", and "specific users", but you can also extend your own set of access rules on top of this, such as "by role", etc. Access control is customizable at the operation-level, for example you can set this to "everyone" can read, but "only me" can update. To enable the Query Presets within a particular collection, set `enableQueryPresets` on that collection's config. Here's an example: ```ts { // ... enableQueryPresets: true } ``` Once enabled, a new set of controls will appear within the list view of the admin panel. This is where you can select and manage query presets. General settings for Query Presets are configured under the root `queryPresets` property. This is where you can customize the labels, apply custom access control rules, etc. Here's an example of how you might augment the access control properties with your own custom rule to achieve RBAC: ```ts { // ... queryPresets: { constraints: { read: [ { label: 'Specific Roles', value: 'specificRoles', fields: [roles], access: ({ req: { user } }) => ({ 'access.update.roles': { in: [user?.roles], }, }), }, ], } } } ``` Related: #4193 and #3092 --------- Co-authored-by: Dan Ribbens <dan.ribbens@gmail.com>	2025-03-24 13:16:39 -04:00
Sasha	117949b8d9	test: regenerate payload-types.ts for all test suites (#11238) ... Regenerates `payload-types.ts` for all test suites.	2025-02-18 00:45:59 +02:00
Alessio Gravili	c7138b9aab	chore: update generated types for all test suites (#9577)	2024-11-27 20:36:37 +00:00
Jacob Fletcher	c96fa613bc	feat!: on demand rsc (#8364) ... Currently, Payload renders all custom components on initial compile of the admin panel. This is problematic for two key reasons: 1. Custom components do not receive contextual data, i.e. fields do not receive their field data, edit views do not receive their document data, etc. 2. Components are unnecessarily rendered before they are used This was initially required to support React Server Components within the Payload Admin Panel for two key reasons: 1. Fields can be dynamically rendered within arrays, blocks, etc. 2. Documents can be recursively rendered within a "drawer" UI, i.e. relationship fields 3. Payload supports server/client component composition In order to achieve this, components need to be rendered on the server and passed as "slots" to the client. Currently, the pattern for this is to render custom server components in the "client config". Then when a view or field is needed to be rendered, we first check the client config for a "pre-rendered" component, otherwise render our client-side fallback component. But for the reasons listed above, this pattern doesn't exactly make custom server components very useful within the Payload Admin Panel, which is where this PR comes in. Now, instead of pre-rendering all components on initial compile, we're able to render custom components _on demand_, only as they are needed. To achieve this, we've established [this pattern](https://github.com/payloadcms/payload/pull/8481) of React Server Functions in the Payload Admin Panel. With Server Functions, we can iterate the Payload Config and return JSX through React's `text/x-component` content-type. This means we're able to pass contextual props to custom components, such as data for fields and views. ## Breaking Changes 1. Add the following to your root layout file, typically located at `(app)/(payload)/layout.tsx`: ```diff /* THIS FILE WAS GENERATED AUTOMATICALLY BY PAYLOAD. */ /* DO NOT MODIFY IT BECAUSE IT COULD BE REWRITTEN AT ANY TIME. */ + import type { ServerFunctionClient } from 'payload' import config from '@payload-config' import { RootLayout } from '@payloadcms/next/layouts' import { handleServerFunctions } from '@payloadcms/next/utilities' import React from 'react' import { importMap } from './admin/importMap.js' import './custom.scss' type Args = { children: React.ReactNode } + const serverFunctions: ServerFunctionClient = async function (args) { + 'use server' + return handleServerFunctions({ + ...args, + config, + importMap, + }) + } const Layout = ({ children }: Args) => ( <RootLayout config={config} importMap={importMap} + serverFunctions={serverFunctions} > {children} </RootLayout> ) export default Layout ``` 2. If you were previously posting to the `/api/form-state` endpoint, it no longer exists. Instead, you'll need to invoke the `form-state` Server Function, which can be done through the _new_ `getFormState` utility: ```diff - import { getFormState } from '@payloadcms/ui' - const { state } = await getFormState({ - apiRoute: '', - body: { - // ... - }, - serverURL: '' - }) + const { getFormState } = useServerFunctions() + + const { state } = await getFormState({ + // ... + }) ``` ## Breaking Changes ```diff - useFieldProps() - useCellProps() ``` More details coming soon. --------- Co-authored-by: Alessio Gravili <alessio@gravili.de> Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com> Co-authored-by: James <james@trbl.design>	2024-11-11 13:59:05 -05:00
Anders Semb Hermansen	4d44c378ed	feat: sort by multiple fields (#8799) ... This change adds support for sort with multiple fields in local API and REST API. Related discussion #2089 Co-authored-by: Dan Ribbens <dan.ribbens@gmail.com>	2024-10-24 15:46:30 -04:00