Demo follow-ups: editable policy name, one-page signup, group classes in upcoming lessons, deletion cleanup

Five items from the latest demo pass:

- A policy's title can be edited from the Policies screen. Only the title
  moves; the slug is what the gates resolve policies by, so a rename can
  never detach a policy from acceptances already recorded against it.
- Signup is one page again. The studio's registration questions move from
  a second step behind "Next" onto the main form, in an "About you" panel
  above the students being added, and that panel also asks an adult
  student for their birth year (the same us_birth_year meta a child's
  uses). register.js disables and hides the whole panel for a pure
  guardian, since the questions describe a student.
- The password is re-scored on submit, not only as it is typed. zxcvbn's
  dictionary arrives after page load, so a password typed straight away
  was never scored at all and the first the student heard of it was the
  server rejecting the whole form.
- Group-class sessions appear alongside lessons wherever upcoming lessons
  are listed: the [us_scheduler] panel (students and instructors) and the
  admin student detail page. GroupClass\SessionSchedule derives them from
  Offering::sessionWindows(), the same derivation the billing scan uses.
  They carry kind = 'group_class' and no Cancel action - a session is one
  date in a term, not a booked slot.
- Deleting a user releases what the account was holding: each upcoming
  lesson is cancelled, its slot freed for rebooking, its pending payment
  voided, and active class enrolments cancelled. Past lessons and paid
  history are left alone.

Tests: composer test (851), composer lint, composer cs all pass.

Co-Authored-By: Claude Opus 5 <[email protected]>

assets/js/booking.js

@@ -588,6 +588,9 @@
     function lessonStatusLabel(status) {
         if (status === 'pending') return 'Pending payment';
         if (status === 'confirmed') return 'Confirmed';
+        // A group-class session carries its enrolment's status, and "active"
+        // reads as jargon next to "Confirmed".
+        if (status === 'active') return 'Enrolled';
         return status.charAt(0).toUpperCase() + status.slice(1);
     }
 
@@ -603,21 +606,31 @@
         return ` <span class="us-my-lesson-who">— ${escHtml(String(l.student_name))}</span>`;
     }
 
+    // A group-class session is a date in a term, not a booked slot: there is no
+    // lesson to cancel and no time to release, so it carries no Cancel button.
+    // Withdrawing from the class is a separate decision, made on the class page.
+    function isGroupSession(l) {
+        return l.kind === 'group_class';
+    }
+
     function lessonRowHtml(l) {
-        const title    = l.offering_title ? escHtml(String(l.offering_title)) : 'Lesson';
+        const group    = isGroupSession(l);
+        const title    = l.offering_title ? escHtml(String(l.offering_title)) : (group ? 'Group class' : 'Lesson');
         const duration = l.duration_minutes ? ` <span class="us-my-lesson-duration">(${escHtml(String(l.duration_minutes))} min)</span>` : '';
+        const badge    = group ? ' <span class="us-my-lesson-kind">Group class</span>' : '';
+        const action   = group ? '' : `<button type="button" class="us-cancel-lesson" data-lesson-id="${l.id}">Cancel</button>`;
         // The two columns are divs, not spans: as spans the layout only held up
         // while the stylesheet's display:flex won, and a theme rule on span
         // collapsed the row onto itself.
         return `
             <div class="us-my-lesson">
                 <div class="us-my-lesson-info">
-                    <strong class="us-my-lesson-title">${title}${duration}${lessonWhoHtml(l)}</strong>
+                    <strong class="us-my-lesson-title">${title}${duration}${badge}${lessonWhoHtml(l)}</strong>
                     <span class="us-my-lesson-when">${escHtml(dayLabel(dayKey(l.start_dt)))} · ${escHtml(timeOf(l.start_dt))}–${escHtml(timeOf(l.end_dt))}</span>
                 </div>
                 <div class="us-my-lesson-actions">
                     <span class="us-lesson-status us-lesson-status-${escHtml(String(l.status))}">${escHtml(lessonStatusLabel(String(l.status)))}</span>
-                    <button type="button" class="us-cancel-lesson" data-lesson-id="${l.id}">Cancel</button>
+                    ${action}
                 </div>
             </div>`;
     }
@@ -634,13 +647,19 @@
         const visible = upcoming.slice(0, INITIAL_LESSON_COUNT);
         const hidden  = upcoming.slice(INITIAL_LESSON_COUNT);
 
+        // Named for what the list actually holds now that group-class sessions
+        // sit in it alongside booked lessons.
+        const heading = upcoming.some(isGroupSession)
+            ? 'Your upcoming lessons and classes'
+            : 'Your upcoming lessons';
+
         myLessons.innerHTML = `
             <div class="us-my-lessons">
-                <h3>Your upcoming lessons</h3>
+                <h3>${heading}</h3>
                 ${visible.map(lessonRowHtml).join('')}
                 ${hidden.length ? `
                     <div class="us-my-lessons-more" hidden>${hidden.map(lessonRowHtml).join('')}</div>
-                    <button type="button" class="us-show-all-lessons">Show all ${upcoming.length} lessons</button>
+                    <button type="button" class="us-show-all-lessons">Show all ${upcoming.length}</button>
                 ` : ''}
             </div>`;
 

assets/js/register.js

@@ -4,18 +4,14 @@
  * Two independent behaviours, both optional — without JS every panel stays
  * visible and the single submit still works:
  *
- * 1. **Two steps.** When account-signup questions are configured the form
- *    renders two panels (`[data-step="1"]` account details, `[data-step="2"]`
- *    the questions) inside a form marked `data-steps="1"`. Step two is hidden
- *    behind a "Next" button that only advances once step one passes native
- *    validation.
- * 2. **Who are you registering?** The student section is hidden until the
+ * 1. **Who are you registering?** The student section is hidden until the
  *    choice is "on behalf of students" or "both", and "Add another student"
  *    clones the student block. "On behalf of students" *alone* also takes the
- *    account holder's own question panel out of play — they are not a student
- *    in that case, so the server ignores those answers and the browser must not
- *    demand them. Under "both" they are a student and do answer them.
- * 3. **Password strength.** The password is scored with zxcvbn (via WordPress's
+ *    account holder's own **About you** panel out of play — they are not a
+ *    student in that case, so the server ignores their birth year and answers
+ *    and the browser must not demand them. Under "both" they are a student and
+ *    do fill it in.
+ * 2. **Password strength.** The password is scored with zxcvbn (via WordPress's
  *    own `wp.passwordStrength`) and a weak one is refused. The server applies
  *    its own, coarser rule regardless — see `Auth\PasswordPolicy`.
  */
@@ -28,10 +24,15 @@
 	 * Gate the form on password strength.
 	 *
 	 * The verdict is attached to the field with `setCustomValidity()` rather than
-	 * by disabling the submit button: the form has up to three submits (the plain
-	 * one, the guardian-mode early one, and step two's) plus a "Next" that
-	 * already gates on `checkValidity()`, and an invalid field blocks all of them
-	 * at once without any of them having to know why.
+	 * by disabling the submit button: an invalid field blocks the submit without
+	 * the button having to know why.
+	 *
+	 * It is also re-scored on submit, which is the case the input handler alone
+	 * misses. zxcvbn's dictionary arrives after page load, and until it does the
+	 * meter has no opinion and the field is left valid — so a password typed in
+	 * the first second and submitted straight away would otherwise never be
+	 * scored at all, and the first the student heard of it would be the server
+	 * rejecting the whole form.
 	 */
 	function enhancePassword(form) {
 		var field = form.querySelector('#us-reg-pass');
@@ -120,49 +121,17 @@
 		for (var i = 0; i < sources.length; i++) {
 			sources[i].addEventListener('change', assess);
 		}
-	}
 
-	function enhanceSteps(form) {
-		var step1 = form.querySelector('[data-step="1"]');
-		var step2 = form.querySelector('[data-step="2"]');
-		var next = form.querySelector('.us-reg-next');
-		var back = form.querySelector('.us-reg-back');
+		// Native validation has already run by the time `submit` fires, so a
+		// verdict reached here has to stop the submit by hand.
+		form.addEventListener('submit', function (event) {
+			assess();
 
-		if (!step1 || !step2 || !next) {
-			return null;
-		}
-
-		function show(step) {
-			step1.hidden = step !== 1;
-			step2.hidden = step !== 2;
-		}
-
-		show(1);
-
-		next.addEventListener('click', function () {
-			var fields = step1.querySelectorAll('input, select, textarea');
-
-			for (var i = 0; i < fields.length; i++) {
-				if (!fields[i].checkValidity()) {
-					fields[i].reportValidity();
-					return;
-				}
+			if (!field.checkValidity()) {
+				event.preventDefault();
+				field.reportValidity();
 			}
-
-			show(2);
 		});
-
-		if (back) {
-			back.addEventListener('click', function () {
-				show(1);
-			});
-		}
-
-		return {
-			step2: step2,
-			next: next,
-			earlySubmit: form.querySelector('.us-reg-submit-early'),
-		};
 	}
 
 	/**
@@ -198,9 +167,10 @@
 		}
 	}
 
-	function enhanceGuardian(form, steps) {
+	function enhanceGuardian(form) {
 		var choices = form.querySelectorAll('.us-registering-for');
 		var children = form.querySelector('#us-children');
+		var self = form.querySelector('#us-reg-self');
 
 		if (!choices.length || !children) {
 			return;
@@ -224,12 +194,15 @@
 		 * each:
 		 *
 		 * - Are student blocks in play? For "students" and "both".
-		 * - Does the account holder answer the studio's questions themselves? For
-		 *   "self" and "both" — they are a student in those two, and the questions
-		 *   describe a student. A pure guardian answers them per student instead,
-		 *   so their own copy goes out of play; disabling it rather than hiding it
-		 *   is what stops a `required` question the server will ignore from
-		 *   blocking submit.
+		 * - Is the account holder a student themselves? For "self" and "both" —
+		 *   only then are they asked for their own birth year and answers. A pure
+		 *   guardian gives those per student instead.
+		 *
+		 * Each panel is disabled as well as hidden. Disabling is what actually
+		 * settles it: a `required` field inside a hidden container makes the form
+		 * unsubmittable with no way to reach the offending control, and a disabled
+		 * fieldset is neither validated nor submitted. The server enforces the
+		 * same rules either way.
 		 */
 		function sync() {
 			var current = mode();
@@ -237,32 +210,18 @@
 			var asksSelf = current !== 'students';
 
 			children.hidden = !wantsStudents;
+			children.disabled = !wantsStudents;
 
-			// Each student's name and birth year are required, but only once the
-			// block is in play: a `required` field inside a hidden container makes
-			// the form unsubmittable with no way to reach the offending control, so
-			// the attribute goes on and comes off with the block itself. The server
-			// enforces the same rule either way.
+			// Belt and braces alongside the disabled fieldset, so the required
+			// state is right if a browser ever renders the block on its own.
 			var required = children.querySelectorAll('[data-us-child-required]');
 			for (var r = 0; r < required.length; r++) {
 				required[r].required = wantsStudents;
 			}
 
-			if (!steps) {
-				return;
-			}
-
-			var fields = steps.step2.querySelectorAll('input, select, textarea');
-			for (var i = 0; i < fields.length; i++) {
-				fields[i].disabled = !asksSelf;
-			}
-
-			// With the questions out of play there is no second step to advance to,
-			// so "Next" would be a dead end — swap it for the submit.
-			steps.next.hidden = !asksSelf;
-
-			if (steps.earlySubmit) {
-				steps.earlySubmit.hidden = asksSelf;
+			if (self) {
+				self.hidden = !asksSelf;
+				self.disabled = !asksSelf;
 			}
 		}
 
@@ -292,11 +251,7 @@
 		var forms = document.querySelectorAll('.us-register-form form');
 
 		for (var i = 0; i < forms.length; i++) {
-			var steps = forms[i].getAttribute('data-steps') === '1'
-				? enhanceSteps(forms[i])
-				: null;
-
-			enhanceGuardian(forms[i], steps);
+			enhanceGuardian(forms[i]);
 			enhancePassword(forms[i]);
 		}
 	});