## Context Personal-namespace projects have no group, so the existing group-routed setup flow (`Groups::Observability::SetupController`, `group_observability_setup_path`) is unreachable for them. User namespaces have no controller surface (`Groups::ApplicationController` cannot resolve a personal namespace), so the setup page must be **project-routed, operating on `project.namespace`**. ## Sequencing #118 → **this issue** → #119. Links to observability must not appear until observability can be enabled, so this MR ships with **no user-facing change**: the new pages are fully functional but reachable only by direct URL. #119 then lands last as the single visibility switch (menu items, `Projects::ObservabilityController` wiring, `observability_anchor_data`). ## Decisions (confirmed) 1. **CI variable**: create a **project-level** `GITLAB_OBSERVABILITY_EXPORT` variable on the initiating project (user namespaces cannot hold CI variables). 2. **Permission threshold**: **owner-only** — `create_observability_access_request` granted in the **project** section of `config/authz/roles/owner.yml` (not developer.yml). 3. **Group projects on the new routes**: **redirect** to `group_observability_setup_path(project.group)` (single canonical setup surface per setting owner). 4. **Copy**: state explicitly that enabling observability applies to **all projects in the user's personal namespace** (onboarding card near the Enable button and on the endpoint configuration page). ## Implementation ### 1. Routes + controllers In `config/routes/project.rb` (next to existing observability routes, ~line 521): ```ruby namespace :observability do resource :setup, only: [:show], controller: 'setup' resource :access_requests, only: [:create] end ``` - New `Projects::Observability::BaseController` mirroring `Groups::Observability::BaseController`: `authenticate_user!`, FF `observability_sass_features` with actor `project.root_namespace`, ability `create_observability_access_request` on the **project**. - `Projects::Observability::SetupController#show`: - `return redirect_to group_observability_setup_path(project.group) if project.group` - Otherwise operate on `project.namespace.observability_group_o11y_setting` (available after #118), including the `PipelinesSinceSetupExist` check and provisioning-param behavior from the group controller. - `Projects::Observability::AccessRequestsController#create`: same redirect rule for group projects; groupless flow calls `Observability::AccessRequestService` with the user namespace + initiating project. ### 2. Permission Add `create_observability_access_request` to the project `raw_permissions` in `config/authz/roles/owner.yml`. Note: maintainers/developers on a personal project will not see the setup page or Enable button; they still get portal access via `read_observability_portal` (#119) once a setting exists. ### 3. Service layer generalization (all currently Group-typed) - `Observability::AccessRequestService`: accept a namespace (+ optional initiating project). `full_path`, `visibility_level`, `projects.first` work on `Namespace`; `members.size` does not exist for user namespaces — branch the issue description (owner instead of member count). Issue title uses `namespace.name`. - `Observability::CreateGroupO11ySettingWorker`: `Group.find_by_id` → `Namespace.find_by_id`; gains a `project_id` argument (nil for group flow). For user namespaces, `add_ci_variable` uses `Ci::ChangeVariablesService.new(container: project, ...)` on the initiating project. - `Ci::Observability::GroupExportWorker` backfill: descendant-group exclusion is irrelevant for user namespaces; add a branch using the namespace's project ids (or skip with follow-up). - `Observability::PipelinesSinceSetupExist`: replace `group.all_active_project_ids` with a namespace-safe equivalent. - `Observability::O11yProvisioningClient`: no code change (only reads `id`/`full_path`); confirm the external provisioner is indifferent to receiving a user-namespace id in `group_id`. - `GroupO11ySetting#gitlab_observability_export_variable`: for user namespaces, check the initiating project's variables instead of group variables (drives the "Ready to collect telemetry" state). ### 4. Views Extract `app/views/groups/observability/setup/show.html.haml` and `_endpoint_configuration.html.haml` into shared partials parameterized on link targets: - Explorer link → `project_observability_path(project, 'dashboard')` - CI/CD settings links (3 places) → `project_settings_ci_cd_path(project)` - Enable button → `project_observability_access_requests_path(project)` - "CI/CD export settings" copy gets a project-variable variant ("your project's variable") - Namespace-neutral wording plus the applies-to-all-personal-projects copy (decision 4) - Note in copy: telemetry export is only auto-wired for the initiating project; other personal projects need the variable set manually. ### 5. Explicitly out of scope (moves to #119) No entry points are wired in this MR. `Projects::ObservabilityController` no-setting handling, monitor menu items, and `observability_anchor_data` all land in #119 so links never render before this destination exists. ## Tests - Request specs for both new controllers: groupless owner renders / can enable; group project 302s to group setup; non-owner 404s; guest 404; FF off 404. - Service spec: namespace branches in `AccessRequestService` (issue description without member count, title from namespace name). - Worker spec: `Namespace.find_by_id`, project-level CI variable creation, group flow unchanged. - `PipelinesSinceSetupExist` with a user namespace. - View/partial specs for both link-target sets. - Policy: owner-only `create_observability_access_request` on project in `spec/support/shared_contexts/policies/project_policy_shared_context.rb` (owner allowed, maintainer/developer disallowed).