v3.5.0

Non-super editors can work with assets again, string fields stop accepting values
that break a record, and tools from other packages can be recommended by discovery.

Some writes that used to succeed are now refused: a list, boolean or object sent to
a string field, an asset copy by a caller without upload {container} assets, and a
container get/update/delete whose handle the resource policy denies.

Added

• Extra tools can be recommended by statamic-system-discover (#76, thanks @illia-sapryga) — a router another package registers can return discoveryKeywords(); discovery scores them like the built-in routers' keywords and recommends the tool with the first sentence of its description as the reason (discoveryReason() to change it) and the right access path (listed_in_catalog or via_execute_tools). Before, discovery only ever recommended the built-in routers, so an intent such as "change a page's SEO title" pointed at statamic-entries and statamic-globals even on a site whose SEO package registered its own tool. discoveryKeywords() returns none by default, so existing tools are unaffected. A switched-off tool is never recommended, a keyword counts once however often it is listed, and a tool whose keywords or reason throw is skipped rather than failing discovery. See Extending: tools.

Security

• Container get, update and delete check the resource policy on the container they act on (#79) — the policy was checked on data.handle when present, while those handlers act on the top-level handle, so an allowed name in data.handle let a caller read, change or delete a container the policy denies. Only create names its container in data.handle.
• Container get checks the permission on the container it returns (#79) — the permission was keyed on container while the handler read handle, so a caller allowed to view one container could read another's configuration.
• Asset copy requires upload {container} assets (#79), as Statamic's own duplicate action does. It used to require move, so an editor who could move but not upload could create new assets.

Fixed

• Editors with per-container asset permissions can use statamic-assets again (#78, #79) — every write handler re-checked a permission Statamic does not have (create assets, edit assets, create asset_containers, …) after the outer check had already enforced the real one (upload {container} assets, configure asset containers, …), so only super admins could upload, update, move, copy or delete assets, or manage containers. The redundant inner checks are gone; the per-container checks still apply.
• configure asset containers covers every asset action (#79), as it does in Statamic's AssetPolicy. A per-container action used to demand the per-container permission alone, so a container admin was refused uploads and edits.
• Container list shows the containers the caller can view (#78, #79) — it required configure asset containers and then returned every container, ignoring the resource policy. It now lists each container the resource policy allows reading and the caller can view.
• String fields refuse values that are not strings (#77, #80) — a text, textarea, slug, markdown, color, link or video field had no input check, and Statamic's own rules let a list through (required passes for a non-empty array). So title: ["a", "b"] was saved and the entry broke when it was rendered. These fields now take a string, cast a number to one, and refuse anything else with an error naming the field, at every level of a record. A value already stored does not block updates to other fields, and a sanitizer registered through FieldtypeExtensions replaces the built-in check.
• Field errors inside sets name the full path (#80) — a bad value in a replicator set, grid row, bard set or group was reported by its own handle alone ([text]); it is now reported as [page_builder.0.text].

Documentation

• docs/tools/overview.md lists the Statamic permission each asset action requires, and the create, update and delete asset rows that were missing from or outside its table.

Full Changelog: v3.4.1...v3.5.0