Report
    Family Shapes + 1Updated May 7, 2026MD

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

    Inventory and rationalization across frontend and backend

    Markdown file

    ../PROJECTS/active/1002_sharing_permissions_privacy_audit.md

    <!-- 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

    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

    Dataset Preview

    • Raw CSV row/table content is available in the source artifact.