Organization Owner Access to Admin Area

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

As an organization owner I want to access the admin area with full administrative capabilities for my organization, so that I can manage users, authentication, sign-up restrictions, and all administrative functions within my organization's isolated boundary.

Context: In the Organizations model, each organization functions as an isolated instance. Organization owners are the administrators of their instance and require access to all administrative controls that affect their organization, excluding only true infrastructure-level settings (hardware, background jobs, Geo replication).

Key decisions:

Reuse instance admin area for organization admins with simplified view

  1. Hide instance-level settings (e.g. hardware remains at instance level)
  2. Show organization switcher for instance admins to access different org admin areas
  3. Focus on .com parity, not self-managed expansion

Acceptance Criteria

Navigation & Access:

  • Organization owners can access admin area via button next to organization avatar (top left)
  • URL pattern: /-/organizations/:org_slug/admin or /-/admin when in org context
  • Admin area automatically scopes all queries to current organization
  • Organization owners see "Organization Administration" title/badge (not "Instance Administration")

User & Authentication Administration:

  • Users Management:
    • View all users in organization (replicate Admin → Users page)
    • Search, filter, sort users (by name, username, email, created date, last activity)
    • View individual user details (profile, activity, groups, projects)
    • Edit user details (can_create_group, projects_limit, can_create_team)
    • Block/Unblock users within organization
    • Approve/Reject pending user accounts (if sign-ups require approval)
    • Invite new users manually
    • Bulk actions: approve, block, delete users
  • Authentication & Sign-up Settings:
    • Configure sign-up restrictions (enabled/disabled, domain allowlist/denylist)
    • Set sign-up approval requirements (automatic vs admin approval)
    • Configure sign-in restrictions (password length, complexity requirements)
    • Set account deletion settings and cleanup policies
  • Access Control:
    • Organization owners cannot access other organizations' admin areas
    • Instance administrators can access any organization's admin area (for GitLab.com support)
    • Clear error message if org owner attempts to access instance-level settings: "This setting is managed at the instance level. Contact GitLab support if you need assistance."

Settings Visible to Organization Owners:

Category Settings Included Scoped to Organization
Users User list, user management, impersonation, 2FA reset, user approval ✓
Sign-up Restrictions Enable/disable registration, domain allowlist/denylist, approval workflow ✓
Sign-in Restrictions Password policies, session duration, email confirmation ✓
Account & Limit Projects per user limit, namespace storage limits, user deletion settings ✓
Visibility & Access Default project visibility, internal visibility enabled ✓
Email Notifications Admin notification email, abuse reports email ✓

Settings Hidden from Organization Owners (Instance-Level Only):

Category Why Hidden
Hardware & System CPU, memory, disk resources managed by GitLab.com
Background Jobs (Sidekiq) Infrastructure-level performance tuning
Geo Replication Multi-site infrastructure not in Org scope
GitLab Runners (instance runners) Org runners coming in Cells; use group/project runners
Monitoring & Performance Prometheus, Grafana, etc. - infrastructure level
Service Templates Being deprecated; project-level integrations used instead
CI/CD Admin Settings (instance) Instance-wide rate limits; org owners set at project/group

Success Metrics

  1. Organization Setup Completion Rate Target: ≥95% of organizations complete user management step during onboarding
    • Measurement: Track organizations that reach "User Management" step AND complete at least one action (invite users, create users, or verify transferred users)
    • Why it matters: Admin area access is required for onboarding, so completion rate indicates whether the user management flow is intuitive and functional
    • Failure mode: Organizations that abandon during user management step indicate UX/functionality issues
  2. User Management Task Success Rate: Target: ≥92% of attempted user management actions complete successfully on first try
    • Measurement: Ratio of successful to attempted actions:
    • Invite existing users: ≥95% success rate
    • Create new users: ≥90% success rate (lower due to form complexity)
    • Verify transferred users: ≥98% success rate (should be simple confirmation)
    • Why it matters: Since this is a mandatory onboarding step, any friction directly impacts adoption Current baseline: Instance admin user management success rate ~87%
Edited by 🤖 GitLab Bot 🤖