Deleted user still appears in organisation admin dropdown

[james-cross]

Summary

When a user is deleted from the database, their email address remains visible and selectable in the organisation administrator dropdown on the organisation details page in the CMS.

Steps to Reproduce

1. Navigate to any organisation listing in the CMS (admin.streetsupport.net/organisations/*)
2. Note a user listed as an admin for that organisation
3. Delete that user from the users database
4. Return to the organisation details page
5. Check the administrator dropdown at the top of the page

Expected Behaviour

The deleted user's email should no longer appear in the organisation administrator dropdown.

Actual Behaviour

The deleted user's email remains visible and selectable in the dropdown, despite no longer existing in the users database.

Additional Context

• Reported by location-admin user
• Issue appears to be generic across organisation listings
• Suggests the dropdown is not properly filtering against current user records
• Could lead to attempting to assign admin rights to non-existent users

Additional Context

• Page URL: Any organisation listing in the CMS
• Content type: organisation details
• Can still reproduce: yes
• Entity: Assume it is generic.
• CMS Role: location admin
• Triage confidence: high

Original report

Reporter: Debbie Tillyer (debbie-chelmsford@streetsupport.net)
Submitted: 2026-04-02T14:36:19.397Z

What they were trying to do:

Deleted the user from an organisation but their email is still listed in the drop down at the top of the organisation as an admin and can be selected for us (despite no longer being in the users database)

What happened instead:

Same as above really. Removing a user from the database doesn't remove their email from the org administrator box on the organisation details page.

Triage reasoning: This is a CMS UI issue where a dropdown component is not properly updating when underlying user data changes. The admin interface should validate user existence when populating dropdowns.

[claude]

Investigation findings

After investigating this repo (streetsupport-platform-admin), the root cause is not here. The fix belongs in streetsupport-platform-api.

What I found in this repo

The administrator dropdown in the CMS is rendered by src/components/organisations/sections/AdminDetailsSection.tsx. It populates its options directly from the organisation.Administrators array, which is whatever the API returns — no filtering, transformation, or caching is applied:

options={localAdministrators.map((admin) => ({ value: admin.Email, label: admin.Email }))}

The data flows in via src/app/api/organisations/[id]/route.ts, which is a thin proxy that forwards the request to the upstream API and returns the response unchanged. There is no layer in this repo where deleted users could be filtered out.

Root cause

The Administrators array stored against an organisation document in MongoDB is not being cleaned up when a user is deleted. The API's user-deletion logic does not cascade to remove (or mark as inactive) the deleted user from the Administrators arrays of any organisations they were associated with.

What likely needs to change in streetsupport-platform-api

• User deletion handler — when a user is deleted, find all organisations where that user's email appears in Administrators and remove the entry.
• Alternatively, the organisation GET endpoint could cross-reference the Administrators list against existing user records and strip out any emails that no longer exist before returning the payload.

The first approach (cascade on delete) is preferable as it keeps the data consistent at rest rather than filtering on every read.