0.0.2-alpha.67

Each drain pass decided which due releases it could mark published by looking every one of them up in the list of all due releases, so the decision grew with the square of the backlog: about two to four seconds at twenty thousand due releases, an imported schedule's size, taken out of a pass bounded to twenty or twenty-five.

The pass now looks them up in a set built once, so the decision grows with the backlog. Which releases may settle, and in what order, is unchanged; a pass only reaches further into a large backlog before its deadline.

When a selection held a visible renamed element and a hidden copy with the same id (hidden by a visibility condition), a link from an unrelated block could keep the old id, which nothing renders once the hidden copy is left off the page. The visible element now decides where such a link points. A hidden element decides only when nothing visible carries that id, so a link and its target stay together when the condition later shows it. Hidden elements still get their own ids put back.

nextly.config.ts, directly in the project, was taken for a file written through a link and skipped, while the routes that import it were written. The project folder is now left out of that check for every file alike, and the folders below it are still checked.

At a production boot, a code-first single was registered without its localized setting, so reads looked for its translated fields on its own table, where a migrated database does not keep them, and every read of a localized single (pages, the REST and Direct API, dashboard widgets) failed with "no such column". The dev server registered it correctly, which hid it. Singles are now registered as collections are.

A table that holds rows is left to nextly db:sync and migrations. The first boot again attempts, and reports, a key to any other table that does not exist yet.

The workspace is the nearest one above the app, up to its repository's root, whose pnpm-workspace.yaml packages or package.json workspaces lists the app; its lockfile names the manager, or pnpm when its pnpm-workspace.yaml lists the app before the first install. An app inside a pnpm workspace no longer gets npm install from an npx launch, and an app no workspace lists keeps the manager that launched the generator, whatever lockfile sits above it. A new project keeps the manager that launched it. When the app already approves a specific esbuild version in pnpm's settings, that rule is kept, and the generator's note, which a failed install now repeats, says to approve the version pnpm names if the install then stops on another one.

The blank and blog templates ship an instrumentation.ts that does it, and adding Nextly to an existing app writes one, or, when the app already has one, leaves it alone and prints the lines to add. Before Nextly has started, /api/health answers 503 with the generic error and logs, once, how to start it.

A notice is for one person only, is stored once per occurrence, keeps a snapshot of what it is about so it still reads after that is deleted, and records when it was read. Read them with GET /api/notices, count them with GET /api/notices/count, and mark them read with POST /api/notices/read, all for the signed-in person (API keys are refused); or from server code with nextly.notices.find(), count() and markRead(). Notices are kept as long as the activity log keeps its records, and are deleted with their person. Core features add their own kinds of notice through one registered, typed kind; plugins cannot add kinds yet. All of this is experimental.

Run nextly migrate to create the nextly_notices table on an existing installation. Until then lists are empty, nothing is recorded, and one warning names the table and the command.

The admin keeps the document's loading, soft lock, recovered-work offer, leave guard and save shortcut around the view, so the plugin implements none of them. Declare a view for one collection under contributes.admin.views[slug].documentViews, or for every collection and Single with a top-level field of a type the plugin contributes under contributes.admin.documentViews with fieldType. navigateTo in @nextlyhq/plugin-sdk/admin moves to another admin page and refuses any other address. PluginDocumentView, PluginFieldTypeDocumentView, DocumentViewProps and navigateTo are experimental. Startup is refused when a view's path is malformed, reserved (versions, api), claimed twice on one document, or offered on a field type its plugin does not contribute.

nextly generate:types now writes the plugin component import map, or removes a stale one, in an app that defines no schema in code. Such an app, whose schema is made in the Schema Builder, rendered empty plugin pages and settings components in a bundled admin, because the map was skipped with the types.

A plugin whose slug is admin could otherwise declare admin.nav as a decision, and core's own admin navigation filter would then be refused on every request.

Through ctx.services.users, an update that would leave an account that way is refused with FORBIDDEN and changes nothing: verifying an active account that has no password, activating a verified one that has none, both at once, or reactivating one core made for a verified person. Core makes those accounts only when one of the app's login plugins hands it a sign-in. Such an account still takes a plugin's other edits, and a plugin may deactivate it or give it a password, but may not move it to another address unless the same write gives it a password. An active account with no password that is not verified stays allowed.

The delivery record of the message keeps the person's kind and id, on the row of the to address, in new principal_kind and principal_id columns of email_deliveries. A person that cannot name one, or names a kind no running plugin registers, is refused before anything is sent.

ctx.principals.reportDeleted now also erases, in the same transaction, the address digest on every delivery record naming the person, and names them there by the keyed digest of kind and id in place of the id. Every record written for the person afterwards, the email telling them their account is gone included, is written without an address digest, even when it is sent inside the report's transaction. Records of anyone else at the same address, a staff user's among them, stay as they were.

Every delivery record is written through one insert, which takes the lock a deletion report waits on; a test holds any new writer to it. nextly migrate and boot add the columns and their index on all three databases, and rewrite no row.

It declares named rules in contributes.limits: rolling windows, or a growing wait after attempts in a row. The app refuses to start on a rule outside the documented bounds. The plugin then reserves through ctx.limits on 1 to 16 entries, each a rule and a key. A reservation is decided and counted atomically in the selected limit store, so instances sharing it admit no more than the rules allow. Each entry chooses whether it can refuse (enforce) and when it counts (count), and gets its own verdict back. release, reset, check and clientKey are there too. A store that can't answer gives unavailable, never an admission. Keys are stored only as keyed hashes, namespaced to the plugin. The types are exported from @nextlyhq/plugin-sdk.

Such a login was recorded on the audit trail as the plugin alone, so a plugin with more than one way in could not be told apart on the rows. Name the method after the colon (acme-google-auth:google); plugins that already do are unaffected.

Collection and field rules receive the person as principal, beside a user that is null, and collection hooks receive them too. A person is admitted only by a code-defined rule that names them, or one set to true: a collection with no rule for the operation refuses them, database permissions and the super-admin bypass never apply, and a person can never publish. Every other caller's rule receives principal: null.

Collection and Single operations on the Direct API, and a plugin's ctx.services collection calls, take a principal option to run as a person. The call is refused before it runs if it also asks to skip access rules or the filterable-field check (frameworkFilter), names a staff user or an API key, or names a person core did not make; any other operation refuses the option, and it cannot be a Direct API instance default. findSingles made as a person lists, and counts, only the Singles the person may read. A document created as a person has no owner. nextly.principals.byId and ctx.principals.byId find a person through the kind's lookup, checked as a resolver's answer is.

An update or delete by where made under access rules (a person's, or any call with overrideAccess: false) now refuses a where on a field the caller may not read before it writes anything, as a read already did; the rows it touched used to answer whether a guessed value matched.

A dev reload now installs the kinds of signed-in person it reads only once it commits, and a kind's attributes may no longer be optional.

AccessControlContext and a field rule's arguments gain a required principal, so code that builds either by hand adds principal: null.

ctx.audit.write takes actorPrincipal and targetPrincipal, by kind and id, kept in new columns of their own. Such a row keeps its network address, browser and metadata. A person's id in actorUserId or targetUserId is still stored as an erased account's, as before.

ctx.principals.reportDeleted(person, { tx }) erases a person from the audit trail in one transaction, the plugin's own when it passes tx. Core clears the address and browser on every row the person acted on, and the plugin metadata on every plugin row naming them. It names the person on those rows by a keyed digest of kind and id, in place of the id, and keeps only that digest and when, in the new nextly_deleted_principals table. Every row written about the person afterwards is written already erased. A report made inside an open transaction without passing it is refused.

The digest's key is made once and kept sealed under NEXTLY_SECRET. After a rotation, keep the old secret in NEXTLY_SECRET_PREVIOUS until the app has started once with both, as for plugin settings.

Every audit row now records which kind of caller acted, in actor_kind: staff, apiKey, core, anonymous, or the person's kind. Rows written before this release keep NULL there and read as before. nextly migrate and boot add the new columns, indexes and table on all three databases, and rewrite no row.

RequestActor gains the principal type for a write made as a person. It carries the person's kind and id and no id, so the activity log, which records staff only, records no row for it. Webhook deliveries still report such a write as system, as they did before.

No deletion report could reach such a row, so the network address, browser and metadata it kept would have outlived the person.

The app now also refuses to start on a kind of signed-in person whose full name, <plugin slug>:<name>, is longer than the 191 characters an audit row stores it in. On PostgreSQL and MySQL every audit write naming such a person failed at the column, and the row was lost with only a log line.

The settings route authenticated the key, then authenticated it again to check its permission, so each read or change of a plugin's settings spent two of the key's requests, and a key with one request left was refused with a 429. The permission is now judged on the caller the route already authenticated.

It registers its own kind of signed-in person in contributes.principals: a name, the attributes the kind exposes with their types, and a resolver that says who is signed in from the plugin's own session. Core names the kind <plugin>:<name>, and the app refuses to start on a kind whose name, attributes or resolver cannot be used, or whose name another plugin's kind already holds.

Core calls a kind's resolver only where an entry point asks for that kind, and at most once per request. A plugin route asks with principal: { kind }. Its handler gets the person as ctx.principal and never staff: the route reads neither the staff session nor an API key, and ctx.auth.currentUser answers no user there. A route that requires the kind refuses a request with nobody of it with the same 401 any route gives an unauthenticated caller. A person's writes take the route's cross-site check as a staff session cookie's do, unless the request carries a Bearer token. principal cannot be combined with public or requiredPermission. Server code asks with ctx.principals.fromRequest or nextly.principals.fromRequest, which answer nobody to a write from another site. nextly plugins info lists each plugin's kinds.

The surface is @experimental until the feature is complete.

Before, the unchanged address was judged as a move to another address and refused with FORBIDDEN, and the unchanged date was judged as a fresh verification, refused for the same reason and, on other accounts, restamped as vouched for by the plugin.

An update that carries an account's address unchanged no longer writes it, so a stale update cannot put back an address another request has since moved the account from. An address stored in mixed case before addresses were lowercased is still rewritten in lowercase, so sign-in can find it. When an address moves, a verification date carried with it is recorded as the updater's vouching, not kept as whoever verified the old address.

The update schema now takes a verification date as a Date or an ISO 8601 date-time string, and refuses any other string with VALIDATION_ERROR. A string failed every update before, and "0" would have parsed as the year 2000.

When a plugin's update is judged, a stored password counts as one when it is a hash core made, or, where the app passes its own passwordHasher to getNextly, whatever that hasher stored.

The plugin services documentation now says that ctx.services.users.create refuses a missing password with VALIDATION_ERROR once an account exists, and with FORBIDDEN on an empty install.

The handler already got no user for such a write; the operator can now see the attempt, as they can when an authenticated route refuses one.

Whether the caller may read related users is now asked once per read, however many relationships point at users, rather than once per field.

An anonymous visitor no longer receives a populated user through a relationship: no visitor can read a user directly, and a user row carries the person's address. Visitors keep populated media, which public pages embed. A page your server renders with the Direct API reads as the system by default and still shows authors.

A relation to a Builder-made collection still resolves; one naming a table or column that does not exist stops the boot with NEXTLY_SCHEMA_RELATION_UNRESOLVED, naming each such relation, instead of failing the first relational query with an internal error. In development it is reported once the boot's schema apply has run, without stopping the dev server.

Pass kind to nextly.releases.create() or POST /api/releases, and read it on every release. A single-document release holds exactly one document. The database refuses a second one, even when two requests add documents to it at once, with a conflict that says to use an ordinary release instead.

find(), count() and GET /api/releases take a kind filter: release leaves out single-document releases and single lists only them. It filters on the stored kind, never on how many documents a release holds.

nextly migrate adds the kind column (existing releases read as release) and a single_slot column on release documents with its unique index. No row is rewritten. kind is experimental.

When a releases run is already in progress, the release goes out with it (or with the next one) and the answer says it is still scheduled. Each release in a list also says whether the reader may publish it now (can.publishNow). Both are experimental. The capabilities type, ReleaseCapabilities, is now exported from nextly/schemas, and the admin reads its release controls from it.

Behaviour change: a cancelled release is now final, like a published one. It can no longer be scheduled again, and documents can no longer be added to or removed from it; create a new release instead. A stopped release can still be fixed and scheduled again.

The check that the document exists read the Single the ordinary way, which creates a Single's row the first time it is read, so a Single that was never saved was accepted, and a blank row was left behind even when the add was then refused. A Single that was never saved is now refused as not found, and nothing is written.

The check also always reads as the caller: a Direct API instance's default API key can no longer stand in for a caller who brought no key of its own.

The Direct API's addMember used to skip what the REST route checked, so a server caller could add a document that does not exist, one in a collection without drafts, or a Single by an id that is not its own. Those are now refused from every caller, with the same errors as over REST, and a Single is recorded by its own stored row. A trusted call (overrideAccess, the default) skips only the read permission.

Finding the releases that are due is now one query on the release's state and time, instead of reading every scheduled release and filtering in memory, so a long list of future releases no longer slows each pass of the drain.

The release target check looked for the Single's row without first registering its table in the process handling the request, so a worker that booted before the Single existed refused a valid add with an error. It now resolves the Single the way every Single read does.

Every change to a release (scheduling, cancelling, stopping, publishing, and adding or removing a document) now advances its revision, and scheduling compares against the one it read: a document removed while a release is being scheduled makes the schedule refuse, rather than leaving a single-document release scheduled with nothing. A release's capabilities now say what a single-document release allows: no scheduling while it is empty, no second document, and no removing its document once scheduled.

For code calling ReleasesRepository directly: scheduleRelease's expectedRevision (added as optional with Publish now) is now required, and from no longer has a default. A schedule fenced only on state cannot tell that a release changed under it, so every scheduling move must name the revision it read: read the release, then pass its revision.

The route is reported, with its content to add, instead. Pages reached through a dynamic segment, such as a site's catch-all page, still leave the routes free to be written.

A production boot refuses a configured plugin that was never installed on its database, so a fresh blog project built for production answered every request with a 500 until nextly plugins install had been run there by hand. Installing again on each build is safe; each run adds one row to nextly_schema_events.

A transform hands back a whole new definition of a collection, Single or component, so nothing stopped it from setting an option the entity's own definition is refused for, such as a collection's db.idType of "serial", or from dropping another plugin's column. Each transformed entity is now validated as its definition would be, and a refusal names the plugin.

A plugin transforming another plugin's entity must now list that plugin in dependsOn, so the owner can't be uninstalled from under the change. It can't move the entity to another table, and it can't remove a field, or change how one is stored, unless it declared that field. An access rule, hook, validator or admin setting a third plugin contributed stays unless the transforming plugin depends on that plugin too. A plugin that transformed another's collection without declaring the dependency stops at boot until it does.

The first correct answer now marks its sign-in answered in the database, in a new table nextly_spent_challenges, by one write only one caller can win, committed before the session is issued. Any later answer to the same pending token is refused, on whichever instance it reaches, before the challenge's resolve runs, and two correct answers at once mint one session. This holds whatever rateLimit.store is set to. The one-shot mark used to live in the rate-limit store, so with the default memory store an answered challenge could be answered again on another instance. A challenge pending across the upgrade is answered against the new mark.

The attempt budget is counted in the limit store rateLimit.store selects, so with "database" wrong answers on every instance spend one budget. An app's own store of the earlier RateLimitStore contract keeps serving it. Its keys, which name an account, are stored only as keyed hashes, so a budget pending across the upgrade starts again. When the store can't be reached, or doesn't answer in time, a two-factor answer is refused with "Please try again shortly." (503) and no session is minted. The boot warning about a per-instance budget no longer appears when the database store is selected or rateLimit.singleInstance is set. Expired marks are removed as new ones are written, an hour after their token's end, so an answer let through before the end always meets them.

AuthRouterDeps gains two optional members, spentChallenges and limitStore, so deps assembled by hand keep working: without spentChallenges, the mark stays in the rate-limit store as before. While an app's own store of the earlier contract is configured, the earlier release's mark is also kept there, so during a rolling upgrade instances of either release refuse a challenge the other settled. nextly/auth exports databaseSpentChallenges and SpentChallenges for such a caller to opt into the database's marks.

Code that calls them compiles as before. A hand-written stand-in for the Nextly interface, such as a test double, must now return token and exp from login, as the real one always has. - A job defined with a typed input, defineJob<{ cursor: string }>(...), now goes into the config's jobs list, or a plugin's contributes.jobs, without a cast. Both lists now take any job, whatever input its handler takes. A value that is not a job is still refused, and a handler is still typed for its own input only, so it can't be called with another job's input. - login() on the Nextly instance from getNextly() is now typed as LoginResult, the user with the session token and its expiry exp, which is what it already returned. The documented result.token now type-checks.

The published baseline, and the comparison that opens on the current draft against what is published, now apply only while the language (or the part of the document with no language) is actually served: after an unpublish, or while a translation has never been published, published is refused with NO_BASELINE and the default opens on the version before. Whether a language is live is now decided in one place for every path, from the main row's status and the translation's own, and a translation's own status is read through one shared reader.

It now refuses to start on a core that does not lend every helper it is built on, and, in production, on limit counts each instance keeps apart.

Staff actions name the account as the audit row's target person rather than in its metadata, and the plugin refuses to start on a core that does not lend it a way to report deletions.

The app gets esbuild as its own dev dependency, so nextly.config.ts can be read and code-first collections load; before, npm left it nested under another package where Nextly could not find it. The install uses the package manager the app's lockfile names rather than the one that launched the generator, so npx create-nextly-app in a pnpm app no longer runs npm over pnpm's install.

On pnpm and Bun, the install scripts of the native packages Nextly brings (the SQLite driver, esbuild and sharp) are approved before the install, in the one place the app's own version reads them and at its workspace root in a monorepo: permissions when pnpm-workspace.yaml has that section (pnpm 12.11+), allowBuilds (pnpm 10.26+), onlyBuiltDependencies (pnpm 10.6 to 10.25), pnpm.onlyBuiltDependencies in package.json (pnpm 10.0 to 10.5), and Bun's trustedDependencies when the app keeps that list. pnpm refused the install until then and the generator stopped with no config or routes written; Bun skipped the SQLite driver's install script and the app answered 500. Only Nextly's packages change: any approval or denial the app already wrote, version-scoped ones included, is kept, pnpm's own placeholder is replaced, and each change is printed. An esbuild the app already declares is left as it is. A project set up this way with an earlier version can add esbuild as a dev dependency and approve these packages the same way, then install again.

When an install fails, the generator now names the exact command to run to see why.

The admin used to remove the host app's favicon links, which React owns, to show its own; it now switches them off and back without removing them, so React can keep updating <head>.

The theme, light, dark or system, is applied to the admin's own containers, its dialogs and menus included, before the first paint, so a dark admin no longer flashes light on load. Native controls such as scrollbars and inputs follow the admin's theme.

ThemeProvider and useTheme from @nextlyhq/admin keep their names and the nextly-theme storage key, and a ThemeProvider inside another still defers to the outer one. ThemeProvider now accepts defaultTheme, storageKey, enableSystem, forcedTheme and nonce; next-themes' other props, such as attribute and disableTransitionOnChange, are no longer accepted, since the admin no longer depends on next-themes. useTheme returns theme, setTheme, resolvedTheme, systemTheme, themes and forcedTheme as before.

A site with a nonce-based Content Security Policy passes its nonce to RootLayout (<RootLayout nonce={nonce} />) or to ThemeProvider, so the admin's small pre-paint script is allowed to run.

A host that puts ThemeProvider around admin content of its own renders <ThemePaintScript /> first inside its .nextly-admin element, so a saved dark theme shows from the first paint. With enableSystem={false} and no defaultTheme, the admin now defaults to light rather than following the system setting.

Any symbol counts, not only @$!%*?&#., and a password over 128 characters is refused before it is sent. Every rule a password misses is listed, not only the first. Choosing "Set a password now" for a new user now says that they choose a new password the first time they sign in, which the server already requires.

Setting a user's password through an update (the admin's edit form, the REST route or the Direct API's users.update) now stores the password exactly as given. It used to trim spaces from its ends before hashing, while account creation and sign-in did not, so a password whose symbol was a leading or trailing space could not be used to sign in. The admin's edit form no longer trims it either. A value of only whitespace still leaves the password unchanged. Existing password hashes are unaffected: only passwords written from now on change.

A check constraint or a foreign key returned by the hook is refused with a pointer to checks or foreignKeys on defineTable, an expression index to indexes, and an enum column to col.enum(). A partial index's refusal no longer promises a later release: partial indexes are refused on every dialect, because MySQL cannot build one.

The generated-types stub no longer mentions a nextly dev command.

Both used to run together on one line above export default.

When the app's app/admin, types/generated or another folder Nextly writes into is a link to a directory elsewhere, nothing is written there, which could have been outside the project. The file is reported as left alone, with the folder that is a link and, for the admin's files, the content Nextly needs, as the media routes already did.

Every request to it is checked against the signed-in caller's media permissions; the public media route stays read-only. The routes import the Nextly config by a path relative to themselves, so no import alias is needed. A media or health route the app already has is left exactly as it was and reported, and for the admin's route the report includes the content to add. A route is not written where a Pages Router page answers its URL (in pages/ or src/pages/), since Next.js refuses to build a page and an app route at one URL; that is reported in the same way.

Before, a nextly.config.ts, admin API route or admin page already there stopped the whole run with an error, and the admin's layout.tsx was written over whatever the app had.

Now every file is created only where nothing is (exclusively, so a link or a file that appears meanwhile is never replaced). One already there is left byte for byte, and the report says so, with why and, for the admin's routes, page and layout, the content Nextly needs there. The report lists each file written, each extended with what was added (the Next config's packages included), and each left alone, across every step, the env files and their warnings included, in one place after the spinner, by path, key and package name only: no env value, the generated secret included, is ever printed.

Until now the expiry was ignored almost everywhere: an expired role kept its permissions in every check, an expired super-admin assignment kept super-admin authority, and login and session refresh still put the role in the session's claims. Cached permission answers, super-admin answers and API key grants now also end no later than the expiry of a role they came from, and a session's access token ends no later than the first of its roles to lapse, so the client refreshes into claims without it.

Assigning a role whose earlier assignment has expired now gives it again, instead of answering that it is already assigned. Listing a user's roles shows only the roles in force. If a user's roles cannot be read at login or refresh, the session is refused rather than issued with no roles.

Permission answers cached in the database before this release are no longer read: they could have come from a role that has since expired. They expire and are cleared as usual, and the first check of each permission after the upgrade is worked out afresh.

Breaking, for code that builds its own AuthRouterDeps for routeAuthRequest (nextly/auth, experimental): the fetchRoleIds(userId) dependency is replaced by fetchSessionRoles(userId), which returns { roleIds, validUntil } (the SessionRoles type, now exported): the role ids in force, and the soonest expiry among them in epoch milliseconds, or undefined when none expires. Read only assignments whose expires_at is empty or later than now. The access token is bounded by validUntil.

A component instance is not a registered block, so the keyboard move could not read its slots and filed the block under the engine's default slot, which an instance draws only when its component exposes it. The move now reads the slots the instance's component exposes and places the block in one of them, and offers no move when the component exposes several and none is the default.

The keyboard move filed the block under a slot name of its own that no core container renders, so the block stayed in the page's data, selected in the inspector and listed in the breadcrumb, while the canvas showed nothing. It now lands in the default slot every core container declares and renders.

Each row of the Layers panel also names the block it stands for in a data-nx-layer attribute, as the canvas already does with data-nx-node. Row labels repeat (every paragraph is "Text"), so a test or an integration had no stable way to find one block's row.

In Chromium the editor's guard heard the history move only after the app's router had already drawn the next page, so pressing Back on a dashboard in customise mode, an entry or a single with unsaved changes left without asking and lost the changes. The guard now listens from the moment the admin loads, ahead of any router.

Before, they printed the message alone, so a refused relation's report left out the code and the relations it named.

On SQLite, a relationship named in camelCase (leadAuthor, stored in lead_author) gave the table drizzle-kit rebuilds a key over a missing column. A long collection and field name made a key name MySQL refuses past 64 characters; it is now shortened with a hash past 63, as other derived names are. And a required relationship that nulls on delete, stored by an older save, no longer refuses every later save of its collection.

Opening a builder address where the builder is off now goes to the dashboard without the editor appearing first, and a failed request shows a message instead of the builder.

Adding a relationship to a Builder collection, or changing a field's type on SQLite, rebuilt or altered the table in a way that dropped the UNIQUE the Builder gives a one-to-one relationship's column, on SQLite and PostgreSQL, so the column then accepted duplicates. While a table held such a column, a SQLite save of another collection could also be refused. Both now keep the constraint. A SQLite save that would rebuild a table with triggers on it is refused, naming the table, instead of dropping the triggers; make that change with a migration that recreates them.

The Builder creates a collection's table with each relationship's key, but every later save went through the schema push, which described no keys. So a relationship added to an existing collection got no key on any database. On SQLite, where a key lives only in the table's definition, a save that changed a field's type rebuilt the table without its key, and a save that rebuilt a collection other collections point at failed outright. A save now adds the key of a relationship it adds, and keeps every key a table already holds through a rebuild, with no delete action running during it. A relationship that was added before this and has no key is left as it is.

That covers Builder collections and singles, and the singles nextly db:sync creates itself. They were created as text, while the schema db:sync compares against names the JSON type, so each such table was offered a conversion its author never asked for. Tables created from now on match.

Existing tables keep their text columns: this changes no stored data, and db:sync still offers to convert them. That conversion succeeds when every stored value is valid JSON. It refuses the whole apply when one is not (an empty string, for example), leaving the column as it was. SQLite is unchanged: it stores JSON as text either way.

Earlier releases stored some passwords as typed instead of hashing them (32 characters or more containing a colon, given when an account was created, or any value sent to PATCH /api/users/:id/password). Such a value never let anyone sign in, but it is readable in the database and its backups.

Run the command once the upgraded version serves every instance, since an old instance can still store a password as typed. Without flags it only counts the affected accounts; with --apply --confirm-default-hasher it clears each stored value and ends that account's sessions, printing only a count: none can be renewed, and an access token already issued lasts until it expires, within fifteen minutes by default. --apply alone changes nothing: the second flag is your statement that no stored password was written by a custom passwordHasher, now or earlier, since the command cannot see one and would take its hashes for plain text. Values in a format other hashers write (an argon2, scrypt or pbkdf2 string in the modular-crypt form their libraries write, or a hex salt and digest joined by a colon) are never counted or cleared; a value that only starts with $ is. nextly migrate now prints the same count and names the command, and changes nothing itself. People whose password was cleared are refused at sign-in exactly as before, and set a new password with Forgot password, or an administrator sets one.

It published three dashboard layout limits from a module that also builds a hash with node:crypto; the limits now come from a module with no imports, and keep their values.

Every entry listed as safe for a browser is now checked: a test walks each one's runtime imports and fails, naming the entry and the path, if any reaches a Node built-in, a database package or a module marked with server-only. The database-operator re-exports, the table DSL and the stored-bytes helper reach server-only code by design and are imported only from server code, so they are listed as server entries; this changes no build output.

Before, an idType the write path did not recognise gave UUIDv4 ids in silence, and an allowIdOnCreate that was not true discarded every id a caller supplied, and any other name in db was not read at all. Now an idType other than uuid or uuidv7, an allowIdOnCreate that is not a boolean, a name that is not an option (a misspelling such as idTyp), and db options that are not an object are refused, naming the option.

serial, which a config carried over from Payload may hold, is refused with its own message: a collection's id is text, which every relation and API path reads. A sequential number, such as an order number, goes on a table keyed by col.serial().

Catalogue sources can report items sold to order, which hold no stock and are capped per line.

Checkout takes no orders until commerce's jobs have run, which is a launch step. Stock and order records keep catalogue references apart exactly, letter case included, on every database.

A client marks a version as seen with PUT …/versions/{n}/seen (people only); the admin doesn't send it yet. API keys and the system are refused, and no read records anything. Marks count by visit: a mark more than 30 minutes after a marker's last one starts a new visit, and "last looked at" is the furthest version of the previous visit, kept per person, document and language. The last-viewed baseline compares from it, falling back to the nearest older version when retention removed it and naming the one removed, and the history list marks the row where you last looked. Markers live in a new core table, nextly_version_views, which nextly migrate creates, and go with their document, collection, Single or person.

Each field carries the label it declares (declaredLabel, or null when it declares none, so a reader applies its own naming rule instead of showing the field's key) and its place among containers (path), including groups with no name, whose heading was lost before. A field the reader may not read is reported in its place as hidden, with nothing of its values, instead of disappearing. Keys with no field are marked system (a framework column such as when the document was first published) or removed, and removed fields are listed last. A comparison with withheld fields is marked incomplete, so "no changes" then means only that nothing the reader may read changed; a changes-only comparison never lists a hidden field. The new response fields are experimental.

Compatibility: FieldDiff gains the hidden member. Code that switches over kind exhaustively needs a hidden case (or a default) after upgrading; the admin draws it as "Hidden: you don't have access to this field".

With neither a from nor a baseline, a comparison opens on the current draft against what is published when both exist, and otherwise on a version against the one before it. A language's first version is refused with NO_BASELINE, and the response names the baseline it used. Core features can register their own baselines. Comparing two named versions works as before. Baselines are experimental.

A push over such a component could plan to drop the column that stores the link. The planner now expects the same column the component table is created with, so a push, migration, or introspection finds no difference.

The documents themselves are named only in the server log, since they were found and read as the system. Documents the usage index cannot vouch for are reported in the server log as unjudged.

Plugin field types gain an experimental write argument on validate: which entry the write is for, and readStored, a read of stored values of the validator's own type on the write's own connection — so a batch's own rows are seen. The page builder's former cycle-guard beforeChange hook is removed; bulk component writes with hooks running are no longer refused for being in a transaction.

Before, the import was seen only on the next save of the config.