0.0.2-alpha.72

Pick an email, and the preview shows each change to the logo, its width, the accent, background and content colours, the font and the footer before anything is saved; a save bar says how many emails a save changes. Where the page builder's site style defines colours, Match my site offers its light-theme colours for each part of the email, suggesting the ones named for each, and the site's font where email clients have it or the closest email-safe one, saying which. The tab says which emails the brand settings reach and why they don't reach the others, and warns when the site's own Default layout keeps them from its emails. Layouts list the emails each one wraps and open in the same workbench as an email, and a layout kept as the previous engine sent it, or with an update from its owner, is said there too. The draft preview (POST /api/email-templates/preview) takes an optional brand change, checked by the rules a save is and laid over the saved settings for that render only.

Check the spelling the Roles screen shows, read-posts. The list a rule is handed holds each permission once, as stored.

A collection's list shows "New" (and the empty list's "Create" and the new-entry shortcut) only to someone who may create there. It shows row checkboxes and the bulk bar only when a bulk action (delete, publish or unpublish) is allowed, and "Delete selected", a row's Delete and the editor's Delete only to someone who may delete. Select-all and the Delete key follow the same answers. The quick-edit and quick-create windows opened from a relationship field offer Save or Create only with the update or create permission; without it the entry is shown read-only. The answers come from the server, code access rules included, and the server still enforces every request.

Deleting a staff user, or a plugin reporting one of its people deleted, cancels every queued email that names them and clears its message, in the deletion's own transaction; erasing an address does the same for queued email to it that names nobody. An email queued for someone already deleted is stored cancelled and never sent, whichever of the two commits first. An attempt already with the provider is left to finish, and its delivery record is written erased.

Held messages are sealed again under the current NEXTLY_SECRET when the app starts after a rotation, while NEXTLY_SECRET_PREVIOUS can still open them, so a queued email stays deliverable across any number of rotations; the server log says how many no configured secret can open.

A queued email now records the person it names, and a new email_queue_recipients table keeps a keyed digest of each recipient, never the address, so an erased address can be found. nextly migrate and boot add both on all three databases.

A single field group's instance sent without its id is still judged as the update its save makes. - Repeated row ids: a repeater or field-group list row repeating another's id takes none of the stored row's protected values, and every row is judged by its own siblings. - Translated groups: in a localized collection, a field group held in a translated group keeps a child its update rule denies, in each language. - Fields named like store columns: a field a field group declares, named like one of the store's own columns (such as updatedAt inside a group), is judged as content when a publish is checked, so a pending edit to it that the publisher may not write is refused rather than lost. - Held drafts in every language: a held draft that removes an instance keeps it when it holds a protected value in any language, without relying on the update's own check. - Protected passwords: an update that clears a field-group instance, or leaves it out of a list, keeps it when a rule protects its password, though the stored hash is never read back.

The data a field write rule reads no longer carries values only the server decides, as the request body sent them: the id, createdAt, updatedAt, createdBy and firstPublishedAt. On an update, id is the stored entry's. On a create, it is there only where the collection keeps the id a create sends (db.allowIdOnCreate), since that is the id the entry is stored under.

The Get started card still withholds such a step. - A failed sample-content load says so. It shows its message and a Retry, instead of the controls disappearing. - Loading sample content, or declining it, counts as acting on the card. A reader who finishes the last step from there is told "You're all set", and the card no longer simply goes. - A staged reset previews the default the reset will land on. It includes Get started even when the reader's own arrangement holds no such card. - The card draws every step the server sends, in the server's order. Runs of Singles still fold, and a step of a kind the admin does not know is drawn, not dropped.

The users, roles, permissions, media, field-group and API-key lists each declare their read gate once, in auth/list-read-gates, and say how it is checked as well as what it asks. The users, roles, permissions and media gates are the system read policy's own, the one the checked Direct API reads, so the REST lists, the dashboard's counts and the Direct API admit the same callers. The list routes and the dashboard summary's counts both read those gates and check them the same way, so a count can no longer be given to a caller its list refuses, or kept from one it admits, after a change to only one of them. The API-key list's reach (every user's keys) is declared there too, and the key count covers what the list shows.

No caller's answer changes. The permissions count is now checked through the any-of check the permissions list uses, rather than the single-grant check. For an API key and for a session the two agree on read-roles.

On MySQL, which matches ids without regard to letter case, a request naming a user or role in another case is stored as that row's own id, and a role named twice in two cases is recognized as one when it would inherit itself.

Nothing has read it since permission answers stopped being stored, so a new install no longer creates it. While an existing database still has it, every access change empties it before the role version is published, so an instance still running an earlier release that reads it, even one upgrading past the release in between, never serves a revoked grant from it. Where PERMISSION_CACHE_ENABLED=false says no instance reads it, it is left as it is. An existing database keeps it, and the startup warning names it with its row count, until nextly migrate runs with NEXTLY_DROP_RETIRED_AUTH_TABLES=1. That drops it even when it holds rows, since they were only copies of answers recomputed from roles, and logs the drop; NEXTLY_DROP_NONEMPTY_RETIRED still governs only the retired accounts and sessions tables. Until the drop, on MySQL, where the table has no foreign key to users, a deleted user's rows stay in it; they name only the user's id and permissions.

The userPermissionCache schema export, deprecated in the previous release, is removed from nextly, nextly/schemas and the dialect schemas in nextly/database, together with the users.permissionCache relation. Nothing in Nextly reads the table, so code that queried it reads only answers no longer written; remove those queries. The name user_permission_cache is reserved, so an app table cannot take it.

Where a rule was letting such users in, grant the permission on the role screen; for this release, each request newly refused this way is logged once, naming the permission to grant.

Publishing every language of an entry or a Single, and writing status: "published" with locale: "*", used to ask the publish rule once, told every language and no single one. A rule answering by language, such as publish: ({ locale }) => locale !== "fr", was then asked with no locale and let French go live. Each of them now asks the rule once for each language going live, with locale set to that language and locales to every language going live, inside the publish, before anything is written. Any refusal refuses the whole publish, so no language goes live; the server log names the languages refused.

Unpublishing every language is still asked once, in every language.

The draft and the document the publish writes are now compared once, as a stored snapshot holds them. So none of these counts as a change:

• a date sent as a Date beside the ISO string the draft keeps;
• part of a component sent back as the draft holds it;
• many-to-many ids in another order.

A Single's own field named createdBy counts as content, as it does for any field a person writes.

Two dashboard fixes:

• A Note's text is drawn as written, so a leading indent keeps its Markdown meaning.
• A layout write holds a placement id reused for another widget to the new widget's text bound.

A widget declaring a limit number setting beside a ranged query is refused at registration and as a contribution, since its range sets how many points are drawn. - applyWidgetSettings returns AppliedQuery<T>: the query as declared with each setting applied, or, for a titled list set to a collection it cannot title, the same with no source and no select. The type is exported from nextly/config.

All of it is @experimental while the content widgets are built.

Each used to read "You don't have permission to perform this action.", which sent people looking for a permission that wouldn't help. One delete that was allowed is now refused. A built-in permission deleted by action and resource, rather than by id, was deleted when it was unassigned. It is now refused as the delete by id always refused it. A hidden internal permission is refused in the generic words, so a delete doesn't confirm it exists.

Refusals for want of permission are unchanged: they never say which check refused.

A production server then serves an upload the moment it finishes, with nothing to add by hand. An app created before this release adds the file itself, as Media & Storage shows.

@nextlyhq/telemetry reaches it through conf and ajv, which validate only telemetry's own consent settings against a fixed schema, so no untrusted URI passes through it. The floor still rises, so no install can resolve an affected version.

Before 2.3.0, one HTTP request within the default size limit could exhaust the server's memory during validation (GHSA-46jr-4wx8-v453); the MCP endpoint validates every request, so it was reachable. Two other advisories fixed in 2.3.0 (GHSA-jm63-cq47-j5jp, GHSA-rvq5-wwqv-78pq) didn't apply: the endpoint already builds a fresh server for each request, and it doesn't use the SDK's bearer authentication. - nextly's optional nodemailer peer moves from ^9.0.1 to ^10.2.1. nodemailer before 10.1.4 had address-parser denial-of-service and parsing flaws (GHSA-prgh-xp8r-p3m5, GHSA-v53p-9fqp-m79j, GHSA-8c8m-p3m8-cjg8 and others), and the SMTP provider passes the addresses it sends to through that parser. Apps using nodemailer for SMTP need nodemailer 10: run npm install nodemailer@^10.2.1. nodemailer 10 needs Node.js 20 or later, which Nextly already requires, and nothing in Nextly's use of it changes. - undici, which @vercel/blob and the jsdom behind HTML sanitizing pull in, moves to 7.30.1, past three denial-of-service and integrity advisories (GHSA-xjj6-f33q-929c, GHSA-4qv8-2p9j-2685, GHSA-f72v-6w45-q472). Neither path was exposed in practice: Vercel Blob's client talks only to Vercel's API, and sanitizing loads nothing over the network.

Startup logs one warning naming each one a site sets. The site's own widgets, declared with defineWidget() as a plugin's are, are checked together with the plugins' widgets, and other keys may name them. - Startup refuses a site config that names a widget that does not exist (with the nearest id), or that uses a key admin.dashboard, an overrides entry or a defaultLayout card does not take (with the key it most likely meant). An id in the collection/ or single/ namespace, a card core derives from the content later, is not refused as unknown at startup; its entry's shape is still checked. It also refuses: - a width a widget does not allow, or widths that widen rather than narrow; - a setting a widget does not declare, or a value it does not accept; - a title or a description that breaks the declaration rules; - a default dashboard with more cards than a dashboard holds, or that lists a widget allowing one card more than once; - a default or a replacement naming a hidden widget, or a replacement no plugin offers for that built-in. - A plugin's suggest and alternatives may name only its own widgets, and an alternative only in place of a built-in that exists. A plugin's dashboard contribution is read once at startup, every check reads that copy, and a key it does not take is refused with the key it most likely meant. - All startup faults are reported together with the widget declarations' own. - AdminDashboardConfig, WidgetRef, DefaultLayoutCard and WidgetOverride are exported from nextly.

All of it is @experimental while the dashboard widget SDK is built.

Send test now reaches only the signed-in person who pressed it: the template's stored copies, such as a team inbox, are left out of the test, which carries sample data. Real sends of the template still copy them.

It is asked in the content language on screen, kept between pages rather than asked again by every component, and asked again on focus, when your soonest role assignment ends, after a change to roles, permissions or role assignments, and after a schema change. Once that role assignment has ended, the earlier answer no longer counts, even if asking again fails. Until the server has answered, no collection or Single is offered. The system sections (users, roles, media, settings, email, webhooks, releases) are still offered from your permission list, and stay available when only the answer about collections fails.

useCan("update-posts") is false for a role that holds update-posts when a code rule on Posts refuses that update, and true where the server allows an action no permission names. The entry editor's publish and unpublish, bulk publish and unpublish, publishing every language, adding to a release and restoring a version follow that answer. Until the server has answered about collections and Singles, such a slug answers false, and once it has, such a slug for a resource the answer does not name answers false except to a super-admin, so give a plugin permission that is not about a collection or Single an action other than those six (export-reports) to check it with useCan. Every other slug (a system resource such as read-webhooks, or a plugin's own permission such as manage-seo) is still answered from the permissions your roles hold. The server still enforces every request either way.

A widget declared with defineWidget and display: { component } is now offered on the dashboard. The admin draws its frame and its loading, no-permission and error states, and hands the component the props its declaration types: WidgetProps (data, settings, size, refreshing, retry). If the component throws while drawing, that card alone shows its error, with Retry.

@nextlyhq/plugin-sdk/admin now exports the widget kit, the parts core's own cards are drawn from: CardSkeleton, CardEmpty, CardUnavailable, CardError, CardFigure, cardNumber, cardChange, GroupsChart and OverTimeChart. They read the card's size and the admin's theme, so a plugin card matches core's in light and dark. defineWidget and the WidgetProps, WidgetRenderSize and WidgetData types are exported from @nextlyhq/plugin-sdk, and the types from ./widgets too. All of it is @experimental.

Import the kit only through @nextlyhq/plugin-sdk/admin. If a second copy of the admin is loaded, development warns about it.

The default is left out for that reader, as the dashboard already leaves out their cards that rely on it. The widget is still offered for the collections they may read; a card they add from it is set to one of those before it saves.