Note

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

    Inventory and rationalization across frontend and backend

    <!-- Migrated from DOCS/WIP_Sharing_Permissions_Privacy_Audit.md on 2025-10-25 -->

    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: ❌

    ...[truncated for intake]

    Provenance