Aug 19 - Update code to catch up with ST

app/enrollment/schema.py

@@ -17,25 +17,41 @@ public form must not import the User model.
 
 # ── Roles a person can be enrolled as ────────────────────────────────────────
 # key -> label, shown in the Step 1 role dropdown.
+# phase51 — enrollment describes CUSTOMER-side people only, so the dropdown
+# offers exactly the two customer roles. Our own staff roles (admin, auditor,
+# internal inspector) are never enrolled through this form; they are created in
+# User Management. The keys stay 'director'/'inspector' — they are the
+# customer's words for the seat, mapped to app roles by APP_ROLE_FOR below.
 ROLES = [
-    ('admin',              'Admin'),
-    ('director',           'Director'),
-    ('auditor',            'Auditor'),
-    ('inspector',          'Inspector'),
-    ('external_inspector', 'External Inspector'),
+    ('director',  'Director'),
+    ('inspector', 'Inspector'),
 ]
 
 ROLE_LABELS = dict(ROLES)
 ROLE_KEYS   = [k for k, _ in ROLES]
 
+#: App role each enrolled seat becomes when an admin actually creates the
+#: account in Customer Management. A plain string map on purpose — the
+#: enrollment package must not import app.models (see __init__.py, rule 88).
+APP_ROLE_FOR = {
+    'director':  'customer',            # "Customer Director"
+    'inspector': 'external_inspector',  # "Customer Inspector"
+}
+
 #: Roles that act on the administrative side of the printed form (the
 #: "Admin / Director" column). Everything else is an inspector seat. Drives
 #: both the recommendation preset and eligibility for admin-only tasks.
-ADMIN_ROLES = {'admin', 'director', 'auditor'}
+#
+#: 'admin' and 'auditor' are NOT selectable any more but stay in this set for
+#: LEGACY tolerance: submissions taken before phase51 stored those roles, and
+#: dropping them here would silently re-render their admin-only task cells
+#: (ref 10) as "n/a" in the admin detail view and the CSV export. Selectable
+#: roles shrink; the ability to read back what was already recorded does not.
+ADMIN_ROLES = {'director', 'admin', 'auditor'}
 
-#: Role pre-selected for the first row — the form starts with one
+#: Role pre-selected for the first row — the form starts with the customer's
 #: administrative contact, as on the printed sheet.
-DEFAULT_FIRST_ROLE = 'admin'
+DEFAULT_FIRST_ROLE = 'director'
 
 #: Upper bound on people per submission. Generous for a real enrollment, but
 #: bounded so a scripted POST cannot make us build an unbounded matrix.
@@ -64,6 +80,20 @@ TASKS = [
 
 TASK_LABELS = {ref: label for ref, label, _ in TASKS}
 
+#: Task rows that describe a CAPABILITY the role already carries, rather than a
+#: notification we route. Every customer role can already do all three today —
+#: comment on issues they follow or filed, log an issue at their own facility,
+#: and search/export reports within their scope — so a tick here records what
+#: the customer expects, it does not switch anything on. The remaining rows
+#: (1-6, 8) are the ones that map to notification events and can be tuned
+#: per account in Customer Management.
+#:
+#: Rendered as a footnote on the public form so the distinction is visible
+#: without turning these into per-user permission flags (which would mean
+#: adding deny-checks to routes that have none today — a fail-open surface for
+#: no real gain).
+ROLE_IMPLIED_TASKS = {7, 9, 10}
+
 
 def task_applies(scope, role):
     """True when a task row offers a checkbox to someone in `role`."""

app/enrollment/templates/enrollment/form.html

@@ -170,6 +170,17 @@
 
     <div class="scroll-x" id="matrixWrap"><!-- table injected by JS --></div>
 
+    {# Rows that come WITH the role rather than being switched on per person.
+       Ticking them records what you expect; it does not change access. #}
+    <div class="form-text mt-2">
+      Rows
+      {% for ref in schema.ROLE_IMPLIED_TASKS | sort %}{% if not loop.first %}{{ ', ' if not loop.last else ' and ' }}{% endif %}{{ ref }}{% endfor %}
+      ({% for ref in schema.ROLE_IMPLIED_TASKS | sort %}{{ schema.TASK_LABELS[ref] }}{{ '; ' if not loop.last }}{% endfor %})
+      are included with the user's role where their access allows it — tick them
+      to record what you expect. The remaining rows control which email and
+      in-app notifications each user receives.
+    </div>
+
     {# ── Step 3 — mobile app ────────────────────────────────────────── #}
     <div class="step-head">
       Step 3: <span>Please check the box next to the user who will receive the