Security/Sharing/Permissions/Privacy/Settings Audit (P1.1)

✅ Phase 1 Status: COMPLETE

Phase 1 (UI Cleanup) has been successfully completed! All identified issues in the Family Tree Settings page have been resolved:

• ✅ Members tab removed (was querying wrong table)
• ✅ Visibility simplified to private/public only
• ✅ allow_edits setting removed from UI
• ✅ require_approval clarified as "Require Approval for Comments"
• ✅ Alert added to Sharing tab explaining temporary vs persistent access
• ✅ Bug fix: Updated count query to use family_tree_collaborators instead of family_tree_members

Build Status: ✅ Compiles successfully with no errors

Next Steps: Phase 2 (Database cleanup) - Remove deprecated fields from database schema

---

This document inventories all current UI and backend surfaces related to sharing, permissions, security, privacy, visibility, and settings, and recommends removals, consolidations, and additions to align with the new family_tree_collaborators model and invitation flow.

Scope

• Frontend: pages, dialogs, panels, widgets using sharing/visibility/permissions/privacy/settings
• Backend: tables, views, functions, RLS policies, edge functions supporting those features
• Settings surfaces: User settings, family tree settings, organization settings, donor privacy settings

Cross-portal positioning and decisions

• 1002 covers audit/alignment across Family, Donor, and Organization portals. It does not implement features; implementation happens in the relevant projects.
• Current Organizations = community-style groups owned by individual users (Facebook Group analogy). Intended scope: group membership, resources/posts, light governance.
• SaaS features (donor database, sibling groups, organization-run family trees with different messaging, analytics, donor tracking) will live in a new SaaS portal project (see mapping below). Do not surface these in current Organization UI.

---

Findings (Comprehensive Inventory)

1. User-Level Settings

src/pages/Settings.tsx - User Account Settings

• Current Features:
  • Privacy Mode toggle (hides profile/trees from public searches)
  • Data Sharing toggle (anonymized data for research)
  • Email Notifications toggle
  • Marketing Emails toggle
  • Data Export dialog
  • Delete Account dialog
• Backend: Uses user_settings table via useUserSettings hook
• Overlap: Privacy mode affects visibility but doesn't interact with tree-level permissions
• Status: unclear if any of the User-Level settings actually do anything.
• Recommendation: Review each user level setting and evaluate if we really need this setting.
• if we do need the setting, then we need to ensure it works. if we do not need it then we need to remove it.
• Action Item: Review each feature individually and decide whether to keep/remove. once that is done,
  • we then need to consider if we need to add any additional user settings.
• Recommendation: Keep as-is - this is user-level privacy, separate from tree collaboration

src/hooks/use-user-settings.ts & src/services/userSettingsService.ts

• Status: does it work as intended? i am not clear if it does.
• Recommendation: Review thoroughly - check if these settings actually affect anything. if yes, then keep. otherwise remove.

---

2. Family Tree Settings (MAJOR OVERLAP AREA)

src/pages/FamilyTreeSettings.tsx - Family Tree Settings ✅ UPDATED (Phase 1)

• Current Tabs (5 tabs total after Phase 1 cleanup):

  1. General: Name, description, visibility (private/public only), layout preferences
  2. Sharing: Uses SharingLinksPanel for temporary sharing links (with clarifying alert message)
  3. Collaborators: Uses CollaboratorPanel ✅ CORRECT - Primary access management
  4. Privacy: Privacy level (strict/moderate/open), allow comments, require approval for comments, notifications
  5. Advanced: Backup settings, export/import, delete tree

• Critical Issues Identified:

  ✅ Issue 1: Members Tab Queries Wrong Table - RESOLVED (Phase 1)

  • Currently queries family_tree_members (person_id - people depicted in tree)
  • Should query family_tree_collaborators (user_id - people who can edit tree)
  • Action Taken: Removed Members tab entirely (redundant with Collaborators tab)

  ✅ Issue 2: Visibility Setting is Ambiguous - RESOLVED (Phase 1)

  • Current values: private, shared, public
  • What does "shared" mean? Shared with collaborators? Shared via link?
  • Action Taken: Simplified to:
    • private: Only collaborators can access (default)
    • public: Anyone with link can view (read-only, no account required)

  ✅ Issue 3: Privacy Settings Overlap with Roles - PARTIALLY RESOLVED (Phase 1)

  • allow_edits setting conflicts with role-based permissions (editor/viewer roles)
  • require_approval is unclear - approval for what? Comments? Edits? New collaborators?
  • Action Taken:
    • Removed allow_edits from UI (DB field remains for now)
    • Clarified require_approval: renamed to "Require Approval for Comments" with clear description
    • Kept allow_comments for public trees with updated description

  ✅ Issue 4: Sharing Tab Only Handles Temporary Links - RESOLVED (Phase 1)

  • Sharing tab creates temporary, expiring links
  • Doesn't create persistent collaborator records
  • Users expect "sharing" to mean "give someone access"
  • Action Taken: Added alert message: "Temporary links for anonymous access. For persistent access, use Collaborators tab."

  ✅ Collaborators Tab is Correct

  • Recently added, uses CollaboratorPanel
  • Correctly queries family_tree_collaborators
  • Action: Promote this as the primary way to manage access

• Recommendations Summary:

  1. ✅ DONE: Remove Members tab - Removed from FamilyTreeSettings.tsx (Phase 1)
  2. ✅ DONE: Simplify visibility to private/public only (removed "shared") (Phase 1)
  3. ✅ DONE: Remove allow_edits setting from UI (Phase 1 - UI only, DB field remains)
  4. ✅ DONE: Clarify require_approval - Updated to "Require Approval for Comments" (Phase 1)
  5. ✅ DONE: Add messaging to Sharing tab - Added alert explaining temporary vs persistent access (Phase 1)
  6. ✅ Keep Collaborators tab as primary access management

src/components/family-trees/SharingSettingsPanel.tsx (exports as SharingLinksPanel)

• Current Features:
  • Create/manage temporary sharing links
  • Set expiration dates and usage limits
  • Access levels: view/edit/admin (but temporary only)
• Backend: Uses sharing_links table and send-sharing-link edge function
• Issues:
  • File name doesn't match export name
  • No clear distinction between temporary links and persistent collaborators
  • Access levels (view/edit/admin) suggest persistent access but links are temporary
• Recommendations:
  1. ✏️ Rename file to SharingLinksPanel.tsx to match export
  2. ✏️ Add clear messaging: "Temporary links for anonymous access. Links expire and don't create user accounts."
  3. 🤔 Consider: Should sharing links create collaborator records when used by authenticated users?
  4. ✏️ Simplify access levels for links: view-only (remove edit/admin for temporary links)

src/components/family-trees/SharingSettingsDialog.tsx

• Status: Wrapper around SharingLinksPanel
• Recommendation: ✏️ Rename to SharingLinksDialog.tsx to match

src/components/family-trees/CollaboratorPanel.tsx ✅ NEW & CORRECT

• Status: Recently added (Oct 2), correctly uses family_tree_collaborators
• Features:
  • List collaborators with roles
  • Invite new collaborators via email
  • Manage roles (owner/admin/editor/viewer)
  • Remove collaborators
• Backend: Uses src/services/familyTreeCollaborators.ts and hooks
• Recommendation: ✅ Keep and expand - this is the correct approach

---

3. Organization Settings (MAJOR OVERLAP AREA)

src/components/organizations/OrganizationSettings.tsx ⚠️ CRITICAL

• Current Tabs (6 tabs total):

  1. Basic: Name, description, visibility (private/public), custom domain
  2. Privacy: Public discovery, member invites, approval required, data sharing level
  3. Donors: Donor database settings, matching preferences
  4. Siblings: Sibling group settings
  5. Communication: Messaging, notifications
  6. Advanced: Delete organization

• Privacy Settings (detailed):

  • allow_public_discovery: Show organization in public searches
  • allow_member_invites: Members can invite others to organization
  • require_approval_for_joins: Admin approval required for new members
  • data_sharing_level: none/members_only/approved_orgs/public
  • share_medical_history: Share medical data
  • share_contact_info: Share contact info
  • share_photos: Share photos

• Critical Issues Identified:

  ❌ Issue 1: Visibility Overlaps with Public Discovery

  • visibility field (private/public) duplicates allow_public_discovery setting
  • Action: Remove visibility field, use allow_public_discovery only

  ❌ Issue 2: Member Invites & Approval Overlap with Roles

  • allow_member_invites and require_approval_for_joins are permission-related
  • Should align with organization member roles (owner/admin/member)
  • Action:
    • Clarify: Only admins+ can invite
    • require_approval_for_joins: Only for public organizations (join requests)

  ⚠️ Issue 3: Data Sharing Settings Don't Integrate with Tree Permissions

  • Organization-wide data sharing settings exist
  • But they don't integrate with tree-level collaborator permissions
  • Unclear if org settings override tree settings or vice versa
  • Action:
    • Clarify hierarchy: Org settings = defaults, tree settings = overrides
    • Document the precedence clearly

  ⚠️ Issue 4: No Organization Collaborator Management

  • Organizations have members but no clear role-based access like trees
  • organization_members table has roles but no UI to manage them
  • Action: Add organization collaborator management UI (similar to tree collaborators)

• Recommendations Summary:

  1. ❌ Remove visibility field (use allow_public_discovery instead)
  2. ✏️ Clarify member invite permissions (admins+ only)
  3. ✏️ Clarify approval workflow (only for public orgs with join requests)
  4. ✏️ Document data sharing hierarchy (org defaults, tree overrides)
  5. 📅 Add organization collaborator management UI (future work)
  6. ❌ De-scope SaaS features from current Organization UI: deprecate Donor Database, Sibling Groups, and Family Trees from community org dashboards; migrate to SaaS portal project.

src/components/groups/GroupSettings.tsx

• Status: Similar to organization settings but for groups
• Recommendation: 📅 Audit separately for similar overlaps (not reviewed in detail yet)

---

4. Donor Privacy Settings (Separate Domain)

src/pages/DonorPrivacy.tsx

• Current Features: Donor-specific privacy controls
• Status: ✅ Separate from tree collaboration; donor-facing
• Recommendation: ✅ Keep as-is - this is donor-specific privacy, not tree permissions

src/components/donor-waitlist/DonorPrivacySection.tsx

• Status: ✅ Privacy settings during donor onboarding
• Recommendation: ✅ Keep as-is

src/components/recipient-dashboard/PrivacyWidget.tsx

• Status: ✅ Privacy widget for recipient dashboard
• Recommendation: ✅ Keep as-is

---

5. Sharing Pages & Components

src/pages/Share.tsx ❌ REMOVE COMPLETELY

• Status: Presentational only; no real actions wired
• Content: Generic sharing page with no functionality
• Recommendation: ❌ Remove completely - redundant with tree settings
• Action Items:
  1. Delete src/pages/Share.tsx
  2. Remove route from src/App.tsx
  3. Remove any navigation links to /share

---

6. Backend Infrastructure

Database Tables

Table	Purpose	Status	Notes
family_tree_collaborators	User-based tree access with roles	✅ NEW	Correct approach
family_tree_invitations	Invitation workflow for collaborators	✅ NEW	Correct approach
family_tree_members	Person-based (people depicted in tree)	⚠️ OLD	Keep for tree membership, not access control
sharing_links	Temporary link-based access	⚠️ EXISTING	Keep but clarify purpose
user_settings	User-level privacy settings	✅ EXISTING	Working correctly
organizations.settings	Organization-level settings (JSONB)	⚠️ EXISTING	Needs cleanup (visibility field)
family_trees.settings	Tree-level settings (JSONB)	⚠️ EXISTING	Needs cleanup (allow_edits field)
family_trees.visibility	Tree visibility (private/shared/public)	⚠️ EXISTING	Simplify to private/public
organization_members	Organization membership with roles	✅ EXISTING	Working but needs UI

Database Functions

Function	Purpose	Status	Notes
has_tree_role(tree_id, user_id, required_role)	Check user role on tree	✅ NEW	Working correctly
has_sharing_link_access(tree_id, link_token)	Validate sharing link	✅ NEW	Working correctly
accept_tree_invitation(invitation_token)	Accept invitation	✅ NEW	Working correctly
user_tree_access view	Convenient view of user's tree access	✅ NEW	Working correctly

Edge Functions

Function	Purpose	Status	Notes
send-sharing-link	Sends emails for temporary sharing links	⚠️ EXISTING	Keep for temporary links
send-invitation	Organization invitations	⚠️ EXISTING	Not for tree collaborators
process-invitation	Organization invitation accept/decline	⚠️ EXISTING	Not for tree collaborators
NEEDED	Tree collaboration invitation email	📅 TODO	Extend existing or create new

RLS Policies

Table	Policy	Status	Notes
family_trees	Role-based SELECT/UPDATE/DELETE	✅ UPDATED	Migration 0007
family_tree_collaborators	Owners/admins can manage	✅ UPDATED	Migration 0007
family_tree_invitations	Inviters and admins can manage	✅ UPDATED	Migration 0007
persons	Collaborators can view/edit	✅ UPDATED	Migration 0007
connections	Collaborators can view/edit	✅ UPDATED	Migration 0007

---

Redundancies & Overlaps Summary

Critical Redundancies (Must Fix)

1. ❌ Members Tab vs Collaborators Tab in FamilyTreeSettings.tsx

   • Members tab queries wrong table (family_tree_members instead of family_tree_collaborators)
   • Collaborators tab is correct
   • Action: Remove Members tab

2. ❌ Visibility Field Duplication in Organizations

   • visibility field (private/public) duplicates allow_public_discovery setting
   • Action: Remove visibility field

3. ❌ allow_edits Setting vs Role-Based Permissions

   • Tree setting allow_edits conflicts with editor/viewer roles
   • Action: Remove allow_edits, use roles

4. ❌ Share.tsx Page

   • Presentational only, no functionality
   • Action: Delete completely

Confusing Overlaps (Must Clarify)

5. ⚠️ Visibility Values (private/shared/public)

   • "shared" is ambiguous
   • Action: Simplify to private/public

6. ⚠️ Sharing Links vs Collaborators

   • Both provide access but different mechanisms
   • Action: Add clear messaging distinguishing temporary vs persistent

7. ⚠️ Organization Data Sharing vs Tree Permissions

   • Unclear hierarchy and precedence
   • Action: Document: org = defaults, tree = overrides

8. ⚠️ require_approval Setting

   • Unclear what requires approval
   • Action: Clarify: only for public tree comments

---

Gaps & Missing Features

High Priority Gaps

1. 📅 Tree Collaboration Invitation Emails

   • Need email flow for tree collaborator invitations
   • Currently only have org invitations
   • Action: Create edge function or extend existing

2. 📅 Organization Collaborator Management UI

   • organization_members table has roles but no UI
   • Action: Create UI similar to tree collaborators

3. 📅 Sharing Link → Collaborator Conversion

   • When authenticated user uses sharing link, should they become a collaborator?
   • Action: Define and implement conversion logic

Medium Priority Gaps

4. 📅 Settings Hierarchy Documentation

   • User settings vs tree settings vs org settings
   • Action: Document precedence and inheritance

5. 📅 Audit Group Settings

   • Similar to org settings, likely has overlaps
   • Action: Conduct separate audit

---

Alignment & Remediation Plan

Phase 1: Critical Fixes (This Week)

1. ❌ Remove src/pages/Share.tsx

   • Delete file
   • Remove route from src/App.tsx
   • Remove navigation links
   • Owner: Frontend
   • Effort: 30 min

2. ❌ Remove Members Tab from FamilyTreeSettings.tsx

   • Delete Members tab code (lines ~223-238)
   • Update tab navigation
   • Owner: Frontend
   • Effort: 1 hour

3. ✏️ Simplify Tree Visibility in FamilyTreeSettings.tsx

   • Change visibility dropdown to private/public only
   • Update database schema if needed
   • Owner: Frontend + Backend
   • Effort: 2 hours

4. ✏️ Remove allow_edits Setting from tree settings

   • Remove from UI
   • Update settings JSONB schema
   • Owner: Frontend
   • Effort: 1 hour

Phase 2: Clarifications (Next Week)

5. ✏️ Rename SharingSettingsPanel → SharingLinksPanel

   • Rename file
   • Update imports
   • Owner: Frontend
   • Effort: 30 min

6. ✏️ Add Messaging to Sharing Tab

   • Add alert/info box explaining temporary vs persistent access
   • Link to Collaborators tab
   • Owner: Frontend
   • Effort: 1 hour

7. ✏️ Clarify require_approval Setting

   • Update label and description
   • Only show for public trees
   • Owner: Frontend
   • Effort: 1 hour

8. ✏️ Remove Organization visibility Field

   • Update UI to use allow_public_discovery only
   • Migrate existing data if needed
   • Owner: Frontend + Backend
   • Effort: 2 hours

Phase 2b: Organization dashboard remediation (Community vs SaaS)

9. ❌ Deprecate SaaS features from current Organization UI

   • Hide/remove Donor Database, Sibling Groups, Family Trees from community org dashboards
   • Add guidance messaging directing users to the SaaS portal project
   • Owner: Frontend
   • Effort: 4 hours

10. 📚 Document cross-portal mapping (see Program ⇄ Project mapping below)

    • Clarify that these features will be implemented under SaaS portal
    • Owner: Documentation
    • Effort: 1 hour

Phase 3: New Features (Following Weeks)

9. 📅 Tree Collaboration Invitation Emails

   • Create edge function or extend existing
   • Integrate with family_tree_invitations table
   • Owner: Backend
   • Effort: 4 hours

10. 📅 Organization Collaborator Management UI

    • Create UI similar to tree collaborators
    • Integrate with organization_members table
    • Owner: Frontend
    • Effort: 8 hours

11. 📅 Sharing Link → Collaborator Conversion

    • Define conversion logic
    • Implement in backend
    • Update UI to show conversion option
    • Owner: Backend + Frontend
    • Effort: 6 hours

12. 📅 Settings Hierarchy Documentation

    • Document user/tree/org settings precedence
    • Add to developer docs
    • Owner: Documentation
    • Effort: 2 hours

---

Tracking & Deliverables

Deliverables

• [ ] Phase 1: Critical fixes (4 items) - Due: End of week
• [ ] Phase 2: Clarifications (4 items) - Due: Next week
• [ ] Phase 3: New features (4 items) - Due: Following weeks
• [ ] Updated documentation reflecting changes
• [ ] Migration guide for any schema changes

Program ⇄ Project Mapping (notation: {projectId}.P{phase})

• 1001 – Family Tree Permissions (core, portal-agnostic)
• 1002 – Sharing/Permissions/Privacy Audit (cross-portal, no implementation)
• 1005 – Organization portal tree permissions/UI (community orgs; leverages 1001)
• 1006 – Donor portal tree permissions/UI (leverages 1001)
• 1008 – SaaS portal for clinics/banks (donor DB, sibling groups, org-run trees with distinct messaging, analytics, donor tracking)

Success Criteria

• ✅ No redundant UI surfaces (Members tab removed, Share.tsx removed)
• ✅ Clear distinction between temporary links and persistent collaborators
• ✅ Simplified visibility settings (private/public only)
• ✅ Role-based permissions consistently used (no allow_edits setting)
• ✅ Clear messaging throughout UI explaining access models
• ✅ Organization settings aligned with tree settings patterns

Timeline

• Audit Complete: 2025-10-03 (TODAY)
• Phase 1 Complete: 2025-10-04 (End of week)
• Phase 2 Complete: 2025-10-11 (Next week)
• Phase 3 Complete: 2025-10-25 (Following weeks)

---

Notes & Open Questions

Decisions & Risks

• Core permissions live in 1001 (portal-agnostic). Portal overlays compose via helper functions and guards; implementation tracked in portal-specific projects (Org 1005, Donor 1006, SaaS 1008).
• Alternatives considered (not chosen now): access_context field and unified "Spaces" model. Revisit under P2 once 1001 stabilizes.
• Risk: attempting Organization remediation before clarifying SaaS scope can confuse users. Add clear UI messaging and documentation links during the transition.

Open Questions

1. Should sharing links create collaborator records when used by authenticated users?

   • Pro: Persistent access, better UX
   • Con: Unexpected for temporary links
   • Decision needed: Product team

2. Should we keep family_tree_members table?

   • Currently used to track which persons are depicted in a tree
   • Not used for access control anymore
   • Decision: Keep for tree membership, rename to clarify purpose?

3. What's the precedence when org and tree settings conflict?

   • Example: Org allows data sharing, tree disallows
   • Decision needed: Product team
   • Proposed: Tree settings override org defaults

4. Should we support "shared" visibility or remove it?

   • Current: private/shared/public
   • Proposed: private/public only
   • Decision needed: Product team
   • Proposed: Remove "shared" (ambiguous)

Future Considerations

• Multi-level permissions: Org → Tree → Person level permissions?
• Permission inheritance: Should tree collaborators inherit org member roles?
• Audit logging: Track permission changes and access attempts?
• Permission templates: Pre-defined permission sets for common scenarios?

---

Appendix: File Inventory

Files to Modify

• src/pages/FamilyTreeSettings.tsx - Remove Members tab, simplify visibility, remove allow_edits
• src/components/family-trees/SharingSettingsPanel.tsx - Rename to SharingLinksPanel.tsx
• src/components/family-trees/SharingSettingsDialog.tsx - Rename to SharingLinksDialog.tsx
• src/components/organizations/OrganizationSettings.tsx - Remove visibility field
• src/App.tsx - Remove /share route

Files to Delete

• src/pages/Share.tsx - Delete completely

Files to Create

• supabase/functions/send-tree-invitation/ - Tree collaboration invitation emails (or extend existing)
• src/components/organizations/OrganizationCollaboratorPanel.tsx - Org collaborator management UI

Files Working Correctly (No Changes)

• src/pages/Settings.tsx - User settings
• src/pages/DonorPrivacy.tsx - Donor privacy
• src/components/family-trees/CollaboratorPanel.tsx - Tree collaborators
• src/services/familyTreeCollaborators.ts - Collaborator service
• src/hooks/useTreePermissions.ts - Permission hooks
• src/hooks/useCollaborators.ts - Collaborator hooks
• src/hooks/useInvitations.ts - Invitation hooks

---

Document Status: 🟡 ACTIVE - Audit complete, implementation in progress
Next Review: After Phase 1 completion (2025-10-04)