* fix: share family accounts with invited members on every sign-up path
A user who joined an existing family through an invitation was added to the
family but saw none of its accounts, even when the family's default sharing is
"share with all members". Only Invitation#accept_for created the AccountShare
records; the OIDC just-in-time sign-up, invite-token registration, and mobile
SSO onboarding paths all skipped it, so invitees landed in the family with an
empty account list. Signups routed into an invite-only default family had the
same gap.
Extract the sharing into Family#auto_share_existing_accounts_with, the single
entry point for "a member just joined, apply the family's sharing policy". It
honors default_account_sharing, only shares with a persisted member of the
family, grants read_only to guests and read_write to everyone else, excludes
accounts the user already owns, and is idempotent. accept_for and every
sign-up path call it, so no current or future join path can reintroduce the
empty-account bug or share accounts across families.
Also wrap the two SSO account-creation paths (OIDC JIT and mobile SSO) in a
transaction covering the user save, invitation acceptance, account sharing, and
identity creation, so a failure partway through can no longer leave a
half-onboarded user with no linked identity.
* address review: guest read_only symmetric in auto_share_with_family!, load-bearing guard comment, mobile SSO private-no-op test
* Add default family selection for invite-only onboarding mode
When onboarding is set to invite-only, admins can now choose a default
family that new users without an invitation are automatically placed into
as members, instead of creating a new family for each signup.
https://claude.ai/code/session_01U9KgikKjV6xbyBZ5wMYsYx
* Restrict invite codes and onboarding settings to super_admin only
The Invite Codes section on /settings/hosting was visible to any
authenticated user via the show action, leaking all family names/IDs
through the default-family dropdown. This tightens access:
- Hide the entire Invite Codes section in the view behind super_admin?
- Add before_action :ensure_super_admin to InviteCodesController for
all actions (index, create, destroy), replacing the inline admin? check
- Add ensure_super_admin_for_onboarding filter on hostings#update that
blocks non-super_admin users from changing onboarding_state or
invite_only_default_family_id
https://claude.ai/code/session_01U9KgikKjV6xbyBZ5wMYsYx
* Fix tests for super_admin-only invite codes and onboarding settings
- Hostings controller test: sign in as sure_support_staff (super_admin)
for the onboarding_state update test, since ensure_super_admin_for_onboarding
now requires super_admin role
- Invite codes tests: use super_admin fixture for the success case and
verify that a regular admin gets redirected instead of raising StandardError
https://claude.ai/code/session_01U9KgikKjV6xbyBZ5wMYsYx
* Fix system test to use super_admin for self-hosting settings
The invite codes section is now only visible to super_admin users,
so the system test needs to sign in as sure_support_staff to find
the onboarding_state select element.
https://claude.ai/code/session_01U9KgikKjV6xbyBZ5wMYsYx
* Skip invite code requirement when a default family is configured
When onboarding is invite-only but a default family is set, the
claim_invite_code before_action was blocking registration before
the create action could assign the user to the default family.
Now invite_code_required? returns false when
invite_only_default_family_id is present, allowing codeless
signups to land in the configured default family.
https://claude.ai/code/session_01U9KgikKjV6xbyBZ5wMYsYx
---------
Co-authored-by: Claude <noreply@anthropic.com>
* Implement dynamic role assignment for new family creators.
Introduced `User.role_for_new_family_creator` to assign `super_admin` to the first user of an instance and a configurable fallback role (e.g., `admin`) to subsequent users. Updated controllers and tests accordingly.
* Update default fallback role for family creators to admin.
---------
Co-authored-by: luckyPipewrench <luckypipewrench@proton.me>
