0.0.2-alpha.70

A change or delete of a collection, Single or component defined in code, made from anywhere but its code, reads "This collection is defined in code, so it can't be changed here." (or "deleted", or "Single", or "component"). An autosave where the collection or Single doesn't autosave reads "Autosave is turned off for this collection." (or "this Single"). Both used to read "You don't have permission to perform this action.", which sent people looking for a permission that wouldn't help.

One status changes. The admin's schema routes checked the lock themselves and answered a thing defined in code with a 500 internal error: changing a Single's schema, previewing or applying a schema change to a collection, Single or component, and deleting a Single. They now answer 403 with the same sentence.

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

Run at the same moment as such a change, a role deletion for instance, it could otherwise deadlock on MySQL and fail with a retryable 409.

It is now refused. Reads keep the public default, publishing still needs a signed-in user, and the admin's REST API is unchanged.

If you take anonymous writes on purpose, say so in the collection's access, for example a public form-like collection: access: { create: () => true }. The form builder's submissions already declare create: true and keep working.

A plugin's deleteEntryInTransaction made { as: "system" } is now trusted, as its other { as: "system" } writes are; it was judged as an anonymous caller.

Installs that never edited these templates get the new colours on their next boot; an edited template keeps its own.

A rule that returns null, undefined, a string or any other value refuses, as false does, for every caller and at every way in. Before, a visitor was refused only by false, so null and undefined let one through, and a signed-in user was let in by any truthy value. Return true to allow.

ctx.caller.can in a plugin route and nextly.access.check now return a boolean. Before, a rule's own answer could come back as it was, null or a string included.

For this release, each request refused this way that a rule allowed before is logged once, naming the collection or Single, the action and the kind of caller, so a rule that relied on the old reading can be found and changed.

Nextly loads Next's unstable_rethrow lazily, which file tracing cannot follow, and on such a bundle (seen on Vercel with Next 16.4.3) loading it failed for every error a handler caught: a signed-out caller's 401, for one, became a 500, so the admin stopped working for anyone signed out. Where it cannot be loaded, Nextly now makes the same check from the errors' digests, so redirect() and notFound() still pass through and every other error gets its own response.

They load them when they first register or build services, so a module that needs one service loads far fewer. The services barrel no longer re-exports the dispatcher; the root nextly entry exports the same names as before.

getService and isServicesRegistered read the container without importing the registry, so code that only looks services up loads far fewer modules. The root nextly entry exports the same names as before.