rimecms 0.31.5 → 0.32.1

package/dist/core/prototype/shared/versions/retire-auto-saves.server.d.ts

@@ -0,0 +1,16 @@
+import type { BuiltArea, BuiltCollection } from '../../../config/types.js';
+import type { RequestEvent } from '@sveltejs/kit';
+/**
+ * Deletes a user's auto-saved rows — of one document, or of every document of the config when
+ * `docId` is not given — except `keep`.
+ *
+ * Bookkeeping, so it runs as rime itself: an editor retiring their own auto-saves need not hold
+ * `access.delete`. `keep` is the row a save just landed on.
+ */
+export declare const retireAutoSaves: (args: {
+    event: RequestEvent;
+    config: BuiltCollection | BuiltArea;
+    userId: string;
+    docId?: string;
+    keep?: string;
+}) => Promise<string[]>;

package/dist/core/prototype/shared/versions/retire-auto-saves.server.js

@@ -0,0 +1,29 @@
+import { withVersionsSuffix } from './naming.js';
+/**
+ * Deletes a user's auto-saved rows — of one document, or of every document of the config when
+ * `docId` is not given — except `keep`.
+ *
+ * Bookkeeping, so it runs as rime itself: an editor retiring their own auto-saves need not hold
+ * `access.delete`. `keep` is the row a save just landed on.
+ */
+export const retireAutoSaves = async (args) => {
+    const { event, config, docId, userId, keep } = args;
+    if (!config.versions?.autoSave)
+        return [];
+    const versionsSlug = withVersionsSuffix(config.slug);
+    return event.locals.rime
+        .collection(versionsSlug)
+        .system()
+        .delete({
+        query: {
+            where: {
+                and: [
+                    { isAutoSave: { equals: true } },
+                    { updatedBy: { equals: userId } },
+                    ...(docId ? [{ ownerId: { equals: docId } }] : []),
+                    ...(keep ? [{ id: { not_equals: keep } }] : [])
+                ]
+            }
+        }
+    });
+};

package/dist/core/prototype/shared/versions/strategy.d.ts

@@ -0,0 +1,86 @@
+import type { BuiltArea, BuiltCollection } from '../../../config/types.js';
+/**
+ * What an update does to a versioned document.
+ *
+ * ```
+ * UPDATE                      no versions: the document's own row is written
+ * UPDATE_VERSION              the selected row is written in place
+ * NEW_VERSION                 a new row is made from the selected one, and written
+ * NEW_AUTO_SAVE_FROM_VERSION  a new auto-saved row is made from the selected one — panel only
+ * ```
+ */
+export declare const VERSIONS_OPERATIONS: {
+    readonly UPDATE: "update";
+    readonly UPDATE_VERSION: "update_version";
+    readonly NEW_VERSION: "new_version";
+    readonly NEW_AUTO_SAVE_FROM_VERSION: "new_auto_save_from_version";
+};
+export type VersionOperation = (typeof VERSIONS_OPERATIONS)[keyof typeof VERSIONS_OPERATIONS];
+export declare const VersionOperations: {
+    /** A row is inserted: a new version or an auto-save. */
+    isNewVersionCreation: (operation: VersionOperation) => operation is "new_version" | "new_auto_save_from_version";
+    /** The new row is an auto-save: the caller's own, reached by its `versionId` only. */
+    isAutoSaveCreation: (operation: VersionOperation) => operation is "new_auto_save_from_version";
+    /** The selected row is written in place. */
+    isSpecificVersionUpdate: (operation: VersionOperation) => operation is "update_version";
+    /** No versions at all. */
+    isSimpleUpdate: (operation: VersionOperation) => operation is "update";
+};
+type Args = {
+    /** A named row. */
+    versionId?: string;
+    /** Make a new version from the selected row rather than write it. */
+    fork?: boolean;
+    /** The panel typing over a document: the write lands on the caller's own auto-saved row. */
+    autoSave?: boolean;
+    /** Whether the row `versionId` names is already an auto-saved one. */
+    originalIsAutoSave?: boolean;
+    config: BuiltArea | BuiltCollection;
+};
+/**
+ * Which row an update starts from is not decided here — `latest` and `versionId` select it, in
+ * `versionsReadQuery`, the same way a read selects one. This decides what is done to it:
+ *
+ * ```
+ * no versions                                UPDATE
+ * autoSave, the named row is an auto-save    UPDATE_VERSION
+ * autoSave, the named row is a version       NEW_AUTO_SAVE_FROM_VERSION
+ * fork                                       NEW_VERSION
+ * no drafts and no versionId                 NEW_VERSION — such a config keeps a version per save
+ * otherwise                                  UPDATE_VERSION
+ *
+ * autoSave, on a config without it or without a versionId   BAD_REQUEST
+ * ```
+ *
+ * Every case, as a request sees it. `latest` and `versionId` mean the same on a `GET`.
+ *
+ * ```
+ * config                  request                              starts from   result
+ * ─────────────────────── ──────────────────────────────────── ───────────── ──────────────────────────
+ * no versions             PATCH                                the only row  written in place
+ *
+ * versions, no drafts     PATCH                                newest        new version
+ * versions, no drafts     PATCH ?versionId=v1                  v1            written in place
+ * versions, no drafts     PATCH ?versionId=v1&fork=true        v1            new version, copy of v1 + body
+ *
+ * drafts                  PATCH                                published     written in place
+ * drafts                  PATCH ?latest=true                   newest        written in place
+ * drafts                  PATCH ?versionId=v2                  v2            written in place
+ * drafts                  PATCH ?fork=true                     published     new draft
+ * drafts                  PATCH ?latest=true&fork=true         newest        new draft
+ * drafts                  PATCH ?versionId=v2&fork=true        v2            new draft
+ * drafts                  any of these + { status: published }               that row published, the others demoted
+ * drafts, none published  PATCH                                —             404: nothing published
+ * drafts, none published  PATCH ?latest=true                   newest        written in place
+ *
+ * auto-save (panel)       ?autoSave=true&versionId=v1          v1            new auto-saved row, status of v1
+ * auto-save (panel)       ?autoSave=true&versionId=a1          a1            written in place
+ * auto-save (panel)       ?versionId=a1                        a1            promoted: a version, status kept
+ * ```
+ *
+ * The panel names the row on screen with every save (`?versionId=<row>`), adds `fork=true` for
+ * "save in a new draft" and for every save on a config without drafts, and types with
+ * `?autoSave=true&versionId=<row>`.
+ */
+export declare function defineVersionUpdateOperation({ versionId, fork, autoSave, originalIsAutoSave, config }: Args): VersionOperation;
+export {};

package/dist/core/prototype/shared/versions/strategy.js

@@ -0,0 +1,93 @@
+import { RimeError } from '../../../errors/index.js';
+/**
+ * What an update does to a versioned document.
+ *
+ * ```
+ * UPDATE                      no versions: the document's own row is written
+ * UPDATE_VERSION              the selected row is written in place
+ * NEW_VERSION                 a new row is made from the selected one, and written
+ * NEW_AUTO_SAVE_FROM_VERSION  a new auto-saved row is made from the selected one — panel only
+ * ```
+ */
+export const VERSIONS_OPERATIONS = {
+    UPDATE: 'update',
+    UPDATE_VERSION: 'update_version',
+    NEW_VERSION: 'new_version',
+    NEW_AUTO_SAVE_FROM_VERSION: 'new_auto_save_from_version'
+};
+export const VersionOperations = {
+    /** A row is inserted: a new version or an auto-save. */
+    isNewVersionCreation: (operation) => operation === VERSIONS_OPERATIONS.NEW_VERSION ||
+        operation === VERSIONS_OPERATIONS.NEW_AUTO_SAVE_FROM_VERSION,
+    /** The new row is an auto-save: the caller's own, reached by its `versionId` only. */
+    isAutoSaveCreation: (operation) => operation === VERSIONS_OPERATIONS.NEW_AUTO_SAVE_FROM_VERSION,
+    /** The selected row is written in place. */
+    isSpecificVersionUpdate: (operation) => operation === VERSIONS_OPERATIONS.UPDATE_VERSION,
+    /** No versions at all. */
+    isSimpleUpdate: (operation) => operation === VERSIONS_OPERATIONS.UPDATE
+};
+/**
+ * Which row an update starts from is not decided here — `latest` and `versionId` select it, in
+ * `versionsReadQuery`, the same way a read selects one. This decides what is done to it:
+ *
+ * ```
+ * no versions                                UPDATE
+ * autoSave, the named row is an auto-save    UPDATE_VERSION
+ * autoSave, the named row is a version       NEW_AUTO_SAVE_FROM_VERSION
+ * fork                                       NEW_VERSION
+ * no drafts and no versionId                 NEW_VERSION — such a config keeps a version per save
+ * otherwise                                  UPDATE_VERSION
+ *
+ * autoSave, on a config without it or without a versionId   BAD_REQUEST
+ * ```
+ *
+ * Every case, as a request sees it. `latest` and `versionId` mean the same on a `GET`.
+ *
+ * ```
+ * config                  request                              starts from   result
+ * ─────────────────────── ──────────────────────────────────── ───────────── ──────────────────────────
+ * no versions             PATCH                                the only row  written in place
+ *
+ * versions, no drafts     PATCH                                newest        new version
+ * versions, no drafts     PATCH ?versionId=v1                  v1            written in place
+ * versions, no drafts     PATCH ?versionId=v1&fork=true        v1            new version, copy of v1 + body
+ *
+ * drafts                  PATCH                                published     written in place
+ * drafts                  PATCH ?latest=true                   newest        written in place
+ * drafts                  PATCH ?versionId=v2                  v2            written in place
+ * drafts                  PATCH ?fork=true                     published     new draft
+ * drafts                  PATCH ?latest=true&fork=true         newest        new draft
+ * drafts                  PATCH ?versionId=v2&fork=true        v2            new draft
+ * drafts                  any of these + { status: published }               that row published, the others demoted
+ * drafts, none published  PATCH                                —             404: nothing published
+ * drafts, none published  PATCH ?latest=true                   newest        written in place
+ *
+ * auto-save (panel)       ?autoSave=true&versionId=v1          v1            new auto-saved row, status of v1
+ * auto-save (panel)       ?autoSave=true&versionId=a1          a1            written in place
+ * auto-save (panel)       ?versionId=a1                        a1            promoted: a version, status kept
+ * ```
+ *
+ * The panel names the row on screen with every save (`?versionId=<row>`), adds `fork=true` for
+ * "save in a new draft" and for every save on a config without drafts, and types with
+ * `?autoSave=true&versionId=<row>`.
+ */
+export function defineVersionUpdateOperation({ versionId, fork, autoSave, originalIsAutoSave, config }) {
+    if (!config.versions)
+        return VERSIONS_OPERATIONS.UPDATE;
+    if (autoSave) {
+        if (!config.versions.autoSave) {
+            throw new RimeError(RimeError.BAD_REQUEST, `${config.slug} does not auto-save`);
+        }
+        if (!versionId) {
+            throw new RimeError(RimeError.BAD_REQUEST, 'an auto-save names the version it starts from');
+        }
+        return originalIsAutoSave
+            ? VERSIONS_OPERATIONS.UPDATE_VERSION
+            : VERSIONS_OPERATIONS.NEW_AUTO_SAVE_FROM_VERSION;
+    }
+    if (fork)
+        return VERSIONS_OPERATIONS.NEW_VERSION;
+    if (!config.versions.draft && !versionId)
+        return VERSIONS_OPERATIONS.NEW_VERSION;
+    return VERSIONS_OPERATIONS.UPDATE_VERSION;
+}

package/dist/core/prototype/shared/versions/types.d.ts

@@ -0,0 +1,37 @@
+import type { BaseDoc } from '../../types.js';
+import type { VersionsStatus } from './constant.js';
+/**
+ * What a version row reads as.
+ *
+ * Was in `core/prototype/types.ts`, which is what made that file import `VersionsStatus` out of
+ * this feature to describe its own registry.
+ */
+export type VersionDoc = BaseDoc & {
+    status: VersionsStatus;
+};
+declare module '$lib/core/prototype/types.js' {
+    interface FeatureDocTypes {
+        version: VersionDoc;
+    }
+}
+/**
+ * What an author writes under `versions`. Lived in `core/config/types.ts`, which is what made
+ * core own the shape of a thing only this folder reads.
+ */
+export type VersionsConfig = {
+    draft?: boolean;
+    autoSave?: boolean;
+    maxVersions?: number;
+};
+/** An auto-saved row, as the panel load hands it to the page: whose typing, and from when. */
+export type AutoSave = {
+    id: string;
+    updatedAt: Date;
+    updatedBy: {
+        id: string;
+        name?: string;
+        email?: string;
+    } | null;
+};
+/** A document's auto-saved rows, newest first. */
+export type AutoSaves = AutoSave[];

package/dist/core/prototype/shared/versions/types.js

@@ -0,0 +1 @@
+export {};

package/dist/core/prototype/shared/versions/validate-config.server.d.ts

@@ -0,0 +1,8 @@
+import type { BuiltArea, BuiltCollection } from '../../../config/types.js';
+/**
+ * What a config declaring `versions` has to look like.
+ *
+ * Same shape as `core/auth/validate-config.ts`: a built config in, its own not-versioned guard
+ * first, messages out. `config/validate.server.ts` folds it in over collections and areas.
+ */
+export declare const validateVersions: (config: BuiltCollection | BuiltArea) => string[];

package/dist/core/prototype/shared/versions/validate-config.server.js

@@ -0,0 +1,21 @@
+/**
+ * What a config declaring `versions` has to look like.
+ *
+ * Same shape as `core/auth/validate-config.ts`: a built config in, its own not-versioned guard
+ * first, messages out. `config/validate.server.ts` folds it in over collections and areas.
+ */
+export const validateVersions = (config) => {
+    if (!config.versions)
+        return [];
+    const errors = [];
+    // An auto-save is a draft row. Without drafts there is no row it could be.
+    if (config.versions.autoSave && !config.versions.draft) {
+        errors.push(`Versions autoSave requires draft: true (${config.slug})`);
+    }
+    // The upload file-reference check reads the newest real row of every document, so a file
+    // only an auto-saved row still names could be removed from disk.
+    if (config.versions.autoSave && 'upload' in config && config.upload) {
+        errors.push(`Versions autoSave is not supported on an upload collection (${config.slug})`);
+    }
+    return errors;
+};

package/dist/core/prototype/shared/versions/write-plan.d.ts

@@ -0,0 +1,30 @@
+import type { WritePlan } from '../../../adapter.js';
+import type { OperationContext } from '../../../pipeline/types.js';
+import type { BuiltArea, BuiltCollection } from '../../../config/types.js';
+/**
+ * A versioned document's write lands on two rows: its identity on the base row, its content on a
+ * version row.
+ *
+ * This is the three-way branch `updatePrototype` used to decode out of `versionOperation`, stated
+ * once, above the adapter, in the feature that owns the distinction:
+ *
+ * ```
+ * not versioned        the plan untouched — the base row holds everything
+ * a specific version   split, and name the row
+ * a new version        split, and name no row: handleNewVersion already wrote it
+ * a create             split, and name no row: none exists yet
+ * ```
+ *
+ * `splitRootData` is what makes a versioned config keep its `$root()` fields on the base row, and
+ * it is this feature's rule to apply, not the adapter's.
+ *
+ * `context.contentOwnerId` is the row, and it is not the same question as this plan's `content`.
+ * That one is "where do this document's blocks, tree nodes and relations hang", which has an
+ * answer in all three cases; this is "which rows does *this write* touch", which has none in the
+ * third. They name the same row when they are both set.
+ */
+export declare const versionsWritePlan: (plan: WritePlan, args: {
+    config: BuiltArea | BuiltCollection;
+    context: OperationContext;
+    operation: "create" | "update";
+}) => WritePlan;

package/dist/core/prototype/shared/versions/write-plan.js

@@ -0,0 +1,38 @@
+import { splitRootData } from '../../../fields/util.js';
+import { VersionOperations } from './strategy.js';
+/**
+ * A versioned document's write lands on two rows: its identity on the base row, its content on a
+ * version row.
+ *
+ * This is the three-way branch `updatePrototype` used to decode out of `versionOperation`, stated
+ * once, above the adapter, in the feature that owns the distinction:
+ *
+ * ```
+ * not versioned        the plan untouched — the base row holds everything
+ * a specific version   split, and name the row
+ * a new version        split, and name no row: handleNewVersion already wrote it
+ * a create             split, and name no row: none exists yet
+ * ```
+ *
+ * `splitRootData` is what makes a versioned config keep its `$root()` fields on the base row, and
+ * it is this feature's rule to apply, not the adapter's.
+ *
+ * `context.contentOwnerId` is the row, and it is not the same question as this plan's `content`.
+ * That one is "where do this document's blocks, tree nodes and relations hang", which has an
+ * answer in all three cases; this is "which rows does *this write* touch", which has none in the
+ * third. They name the same row when they are both set.
+ */
+export const versionsWritePlan = (plan, args) => {
+    // Not versioned: the whole document is on its own row and there is nothing to split.
+    if (!args.config.versions)
+        return plan;
+    const { versionOperation, contentOwnerId } = args.context;
+    // The `$root()` fields stay on the base row; a versions table has no column for them.
+    const { base, content } = splitRootData(plan.data, args.config);
+    // No row to name: this document has no version yet, and the adapter makes the first one.
+    if (args.operation === 'create')
+        return { data: base, content: { data: content } };
+    return VersionOperations.isNewVersionCreation(versionOperation)
+        ? { data: base }
+        : { data: base, content: { id: contentOwnerId, data: content } };
+};

package/dist/core/prototype/types.d.ts

@@ -0,0 +1,79 @@
+import type { GetRegisterType, RegisterArea, RegisterCollection } from '../../index.js';
+export type CollectionSlug = GetRegisterType<'CollectionSlug'>;
+export type AreaSlug = GetRegisterType<'AreaSlug'>;
+export type PrototypeSlug = CollectionSlug | AreaSlug;
+import type { Dic } from '../../util/types.js';
+export type Prototype = 'area' | 'collection';
+export type RawDoc = Dic & {
+    id: string;
+};
+export type BaseDoc = {
+    id: string;
+    title: string;
+    updatedAt?: Date;
+    createdAt?: Date;
+    locale?: string;
+    url?: string | null;
+    _prototype: Prototype;
+    _type: PrototypeSlug;
+    _live?: string;
+};
+export type GenericDoc = BaseDoc & Dic;
+export type GenericNestedDoc = BaseDoc & {
+    _children: string[];
+    _parent: string | null;
+    _position: number;
+} & Dic;
+export type TreeBlock = {
+    id: string;
+    ownerId?: string;
+    path?: string;
+    position?: number;
+    _children: TreeBlock[];
+} & Dic;
+export type GenericBlock<T extends string = string> = {
+    id: string;
+    type: T;
+    ownerId?: string;
+    position?: number;
+    path?: string;
+} & Dic;
+/**
+ * Every document shape there is, by the name a `DocType` uses for it.
+ *
+ * Three sources, and none of them is a list kept here. The two below are core's own — anything is
+ * a raw row or a document. `FeatureDocTypes` is what the features contribute (`upload`, `version`,
+ * `auth`, `directory`), each declared beside the feature that means it. `RegisterCollection` and
+ * `RegisterArea` are what codegen writes for the configs in the build.
+ *
+ * The four feature shapes were spelled out here, which is why this file imported `UploadPath` and
+ * `VersionsStatus` out of two features to describe its own registry.
+ */
+export type Docs = {
+    raw: RawDoc;
+    generic: GenericDoc;
+} & FeatureDocTypes & RegisterCollection & RegisterArea;
+export type DocType = keyof Docs;
+/**
+ * How a feature declares a **document shape** into core's `Docs` registry.
+ *
+ * `Docs` maps a `DocType` to what a document of that type looks like, and four of its entries were
+ * a feature's: `upload`, `version`, `auth` and `directory`. Core declaring them meant
+ * `core/prototype/types.ts` importing `UploadPath` and `VersionsStatus` out of two features to
+ * spell its own registry.
+ *
+ * Merged beside the feature's own types:
+ *
+ * ```ts
+ * declare module '$lib/core/prototype/types.js' {
+ *   interface FeatureDocTypes {
+ *     version: VersionDoc;
+ *   }
+ * }
+ * ```
+ *
+ * The prototype slugs come the other way, through `RegisterCollection`/`RegisterArea`, which
+ * codegen writes. This is the same mechanism for the shapes a feature adds rather than a config.
+ */
+export interface FeatureDocTypes {
+}

package/dist/core/prototype/types.js

@@ -0,0 +1 @@
+export {};

package/dist/core/prototype/when.d.ts

@@ -0,0 +1,25 @@
+import type { Dic } from '../../util/types.js';
+/**
+ * Guards a step with the question that decides whether it applies.
+ *
+ * ```ts
+ * augments: () => [augmentLabel, when(isAuth, augmentAuth), augmentTitle]
+ * beforeRead: [when(isAuth, auth.removePrivateFields), processDocumentFields]
+ * ```
+ *
+ * One helper for both lists, because a step is the same shape in both: it takes a thing, and
+ * hands back that thing — changed if it applies, untouched if it does not. An augment is handed
+ * the config itself; a hook is handed the pipeline's `args`, which carries `config`, and answers
+ * with a promise. `carriesConfig` below is the whole of the difference, and `R` is what lets an
+ * async step through.
+ *
+ * This was two mechanisms. Augments were gated by a `FeatureDefinition.enabled` predicate on a
+ * definition, folded by `applyAugments`; hooks by a `feature: 'auth'` mark on the hook and a
+ * name → predicate map in `buildPipeline`. Neither was visible where the step was placed, which
+ * is the only place the question is interesting.
+ *
+ * A step with no guard runs always — which is what six of the ten features declared anyway.
+ */
+export declare const when: <T, R>(applies: (config: Dic) => boolean, step: (subject: T) => R) => ((subject: T) => R | T) & {
+    step: (subject: T) => R;
+};

package/dist/core/prototype/when.js

@@ -0,0 +1,32 @@
+/**
+ * Guards a step with the question that decides whether it applies.
+ *
+ * ```ts
+ * augments: () => [augmentLabel, when(isAuth, augmentAuth), augmentTitle]
+ * beforeRead: [when(isAuth, auth.removePrivateFields), processDocumentFields]
+ * ```
+ *
+ * One helper for both lists, because a step is the same shape in both: it takes a thing, and
+ * hands back that thing — changed if it applies, untouched if it does not. An augment is handed
+ * the config itself; a hook is handed the pipeline's `args`, which carries `config`, and answers
+ * with a promise. `carriesConfig` below is the whole of the difference, and `R` is what lets an
+ * async step through.
+ *
+ * This was two mechanisms. Augments were gated by a `FeatureDefinition.enabled` predicate on a
+ * definition, folded by `applyAugments`; hooks by a `feature: 'auth'` mark on the hook and a
+ * name → predicate map in `buildPipeline`. Neither was visible where the step was placed, which
+ * is the only place the question is interesting.
+ *
+ * A step with no guard runs always — which is what six of the ten features declared anyway.
+ */
+export const when = (applies, step) => {
+    const guarded = (subject) => applies(carriesConfig(subject) ? subject.config : subject) ? step(subject) : subject;
+    // The guard is transparent to everything that looks at a step: the generated hooks chart reads
+    // `fn.name`, and `.step` says which step a list entry guards. A function's own `name` is
+    // non-writable but configurable, so it takes a defineProperty and not an assignment — and
+    // setting it means the step shows up under its real name in a stack trace too.
+    Object.defineProperty(guarded, 'name', { value: step.name, configurable: true });
+    return Object.assign(guarded, { step });
+};
+/** A hook's `args` carries the config; an augment *is* the config, and has no such member. */
+const carriesConfig = (subject) => typeof subject === 'object' && subject !== null && 'config' in subject;