11 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	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
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
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
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
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