Block self-share on projects and tabular reviews
Owners could share a project or tabular review with their own email, producing redundant member-list entries. willchen96 closed this across three API endpoints and two frontend entry points in one shot, and also added email normalization and deduplication before persistence.
The fix rejects self-share emails at the API boundary on project creation, project updates, and tabular-review updates. The same check runs in the People modal and the new-project flow so the UI doesn't send a request the backend will refuse.
Email normalization and deduplication were added as part of the same change. Before this, the same collaborator could appear multiple times with different casing or whitespace, because nothing enforced a canonical form before writing to storage. The storage shape and the validation logic now agree on what a share entry looks like.
willchen96 framed this as a consistency fix rather than a security one. An owner sharing with themselves never granted additional access - they already have full rights. The practical issue was polluted membership views and ambiguous access states. Applying the same rule across five entry points in one PR is the right way to handle this kind of invariant, since partial coverage is worse than none.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?