v0.14.0

Upgrading to 0.14.0 — roles and permissions replace "everyone can edit everything"

Before this release any member of a workspace could edit issues in every project in it. There was
no way to say otherwise. 0.14.0 replaces that with a permission model, and it is the largest
behavioural change since the board.

Authorization is now one resolution and one check. A request resolves the caller's permissions
once, and each protected action asks for exactly the permission it needs. A refusal names the
permission it wanted rather than saying "forbidden".

Roles are rows, not code. Built-in roles are shared across workspaces; a workspace can define
its own. Creating a custom role is always a duplicate of an existing one, because the rule for
handing out permissions is that you can only grant what you already hold — and a role composed
from an empty checklist could be assigned to nobody.

Projects gained an access mode. OPEN lets non-members inherit a default role; STRICT means
membership is explicit. There is a default project role and a default workspace role behind that,
so a new project is not a blank wall.

Workspace member management exists. Until now a member could be added and never changed or
removed. Roles can be changed and members removed, with the grant ceiling checked at both ends
of the change, so an administrator cannot demote an owner.

A project can no longer be stranded. Removing the last person who can manage a project's
members used to leave it unmanageable by anyone, including the workspace owner. Nine separate
doors now refuse that.

What to expect after upgrading

Nothing is locked down that was open before: existing members keep an equivalent role, so the
first thing you notice is that the screens now say who can do what. Tightening is a decision you
make afterwards, in People and Roles.

The interface reads permissions rather than role names, so a custom role gets the same UI as a
built-in one with no further work.

---

Full Changelog: v0.13.2...v0.14.0