Release Notes

Creating assignments in the gradebook now always ends in success—not a server error.

If a teacher accidentally checked both the "Midterm" and "Final" boxes when adding a regular assignment, the page would crash with a server error instead of showing a helpful message. That's now fixed.

The assignment form now catches this combination before it ever reaches the server, so you'll see a clear validation message right away. We also repaired a longstanding issue where the mutual-exclusion guard in the browser was silently broken—it just wasn't wired up correctly. Both the form and the browser now agree: an assignment can be one or the other, but not both.

Fixes and Improvements¶

• Fixed a 500 error when submitting the regular assignment form with both "Midterm" and "Final" checked simultaneously
• Activated the client-side mutual-exclusion guard for the Midterm and Final checkboxes (it was previously non-functional)
• Added server-side safety nets on all three assignment-creation paths in the gradebook so unexpected validation errors show a friendly message instead of crashing

Stripe Connect onboarding should no longer show a generic error.

If you clicked "Connect with Stripe" on the Payment Settings page and saw "Unable to start Stripe Connect onboarding. Please try again." with no further detail -- we've fixed that. The root cause was insufficient error handling that hid the actual problem (which could be anything from a misconfigured API key to a lost tenant context).

Now, if Stripe isn't properly configured, you'll see a specific message telling you to contact support. If the API call fails, the full error details are logged internally so we can diagnose the issue without asking you to reproduce it.

Fixes and Improvements¶

• Added pre-flight validation that catches misconfigured Stripe API keys before making API calls
• Improved error logging for faster debugging
• Fixed a scenario where tenant context loss could silently swallow the real error

When you try to save a user with an email that's already taken, you now get a clear message — not a cryptic error.

If an administrator tried to update a user's or staff member's email address to one that already belonged to another account, NavEd would show a raw technical error message instead of something helpful. It said something like "Failed to Update User: duplicate key value violates unique constraint..." — which tells you nothing about what to actually do.

We've fixed this so that when you enter an email already in use, you'll see a clear message: "That email address is already in use by another account. Please choose a different email." The edit page stays open so you can correct it right away.

Fixes and Improvements¶

• Fixed confusing error when editing a user or staff member with a duplicate email address
• Improved error handling for the staff edit flow with the same friendly message

Class names are back on the enrollment page.

If you've been trying to enroll students into subjects and noticed the class list looked... empty — you weren't imagining it. The checkboxes and "Enrolled" badges were showing up fine, but the actual subject names were invisible. Not a great experience when you're trying to assign 15 classes to a student.

We tracked this down and fixed it. Subject names now display correctly on both enrollment pages, in both light and dark mode. Thanks to the Compass team for flagging this one.

Fixes and Improvements¶

• Fixed invisible subject names on the student enrollment page
• Fixed the same issue on the subject-first enrollment page

Fixed a security issue where editing a user in one school could overwrite another school's user data.

HODs can now only edit users who have a role (admin, staff, student, or parent) in their own school. Previously, the edit user form did not verify that the target user belonged to the current school before saving changes to the shared user record, which could cause identity corruption across schools.

What's New¶

• Security: school-scoping guard on user edit prevents cross-school identity overwrites
• Security: edit user form page also checks school membership before displaying

Payment webhooks now drive the complete payment lifecycle.

Stripe Connect webhook handlers now process all payment events: successful checkout, expiration, failure, refunds, disputes, and payouts. Each successful payment creates an immutable payment record with a full fee breakdown. Form submissions automatically transition through the correct statuses as events arrive. Parents can retry failed or expired checkouts.

Fixes and Improvements¶

• Fixed crash affecting staff pages with orphaned staff records — those records now display safely instead of crashing the page