Add Member

One person into this school — the same row a pasted roster is made of.

This used to refuse anybody without a FluenTea account: 404 No user with that email. Beside it, /enrolment/commit took fifty strangers and CREATED fifty accounts. Two doors, opposite rules, and the rule was invisible until it failed — a coordinator could paste a hundred people who had never heard of us, and be refused the hundred-and-first typed on its own.

So an address that belongs to nobody is provisioned here exactly as it is in a paste: school_enrolment_service does the classification, the account creation, the activation token and the invitation, and the response carries the activation link so a coordinator can hand it out on paper. There is one implementation, and the outcome words are the list's own — created, enrolled, section_added, already, invalid, failed.

THIS DOOR IS NOT A BULK DOOR. It is the only place a coordinator or an owner may be appointed, because it takes ONE address and runs the role ladder (_require_role_grant) against that one named person first. A list may only hand out ENROLABLE_ROLES (student, teacher) and that has not changed — which is exactly why the widened vocabulary is passed in here rather than read from the service: paste two lines into this box and it is a 400, not two coordinators.

Adding somebody who is already a member reports already and rewrites nothing — not their role, not their name, not their section elsewhere. A coordinator typing their own teacher's address into an add box is not asking to demote them. Re-roling is the PATCH below, a deliberate act with its own authorization.

user_id still works (the id-keyed door, used by operators), and so does premium_until. group_id puts them in a section in the same act.