This would transition the organization state from `soft_deleted` to `active`. Only available to admins. ## Background The `Organizations::Organization` state machine (`Organizations::Stateful`) already defines the `restore` event (`soft_deleted → active`) along with the `clear_soft_deletion_data` callback that resets `soft_deleted_at` and removes `soft_deletion_scheduled_by_user_id` from `state_metadata`. What's missing is the service that wraps this transition with authorization, validation, and logging — the counterpart to the existing `Organizations::SoftDeleteService` and `Organizations::HardDeleteService`. This issue covers the **service layer only**. Exposing it via GraphQL/UI is tracked separately. ## Proposal Add `Organizations::RestoreService`, mirroring `SoftDeleteService`, to transition a soft-deleted organization back to `active`. Restore is **admin-only** (more restrictive than soft/hard delete, which also allow organization owners), so it requires a new `:restore_organization` policy ability rather than reusing `:delete_organization`. ## Implementation plan ### 1. Policy — `app/policies/organizations/organization_policy.rb` Add an admin-only ability: ```ruby rule { admin }.policy do # ...existing admin abilities... enable :restore_organization end rule { blocked | deactivated | inactive }.prevent :restore_organization ``` The `prevent` rule mirrors the existing guard on `:delete_organization` so blocked/deactivated/inactive users can't restore even if otherwise admin. ### 2. Service — `app/services/organizations/restore_service.rb` Mirror `SoftDeleteService` exactly (include `BaseServiceUtility` + `::Gitlab::Loggable`, do **not** inherit `BaseService`, end with `prepend_mod`): ```ruby # frozen_string_literal: true module Organizations class RestoreService include BaseServiceUtility include ::Gitlab::Loggable def initialize(organization, current_user:) @organization = organization @current_user = current_user end def execute return error(_('Insufficient permissions')) unless authorized? return error(_('Organization is not soft-deleted')) unless organization.soft_deleted? organization.restore(transition_user: current_user) return error(organization.errors.full_messages.join(', ')) unless organization.active? log_event ServiceResponse.success(payload: { organization: organization }) end private attr_reader :organization, :current_user def authorized? Ability.allowed?(current_user, :restore_organization, organization) end def error(message) ServiceResponse.error(message: message, payload: { organization: nil }) end def log_event log_info(build_structured_payload( message: "Organization restored", Labkit::Fields::GL_USER_ID => current_user.id, Labkit::Fields::GL_ORGANIZATION_ID => organization.id, organization_path: organization.full_path )) end end end Organizations::RestoreService.prepend_mod ``` Notes: - `transition_user: current_user` is required so the shared `update_state_metadata` and `log_transition` state-machine callbacks record the acting user. - The success guard checks `organization.active?` (the post-transition state), matching how `SoftDeleteService` checks `soft_deleted?`. ### 3. Specs — `spec/services/organizations/restore_service_spec.rb` Mirror `spec/services/organizations/soft_delete_service_spec.rb`, covering: - Unauthorized user → error `Insufficient permissions`. - Non-admin owner → error (verifies the admin-only ability, unlike soft delete). - Authorized admin, organization not soft-deleted (e.g. `active`) → error `Organization is not soft-deleted`. - Authorized admin, organization soft-deleted → transitions `soft_deleted → active`, clears `soft_deleted_at` and `soft_deletion_scheduled_by_user_id`, returns success payload with the organization. - Logs the `"Organization restored"` structured event with `GL_USER_ID`, `GL_ORGANIZATION_ID`, and `organization_path`. Use a soft-deleted organization fixture (e.g. build an `:active` org and call `soft_delete(transition_user: ...)` in a `before`, as the soft-delete spec already does, or add a `:soft_deleted` factory trait if one doesn't exist). ### 4. i18n The two new user-facing strings (`Insufficient permissions` already exists; `Organization is not soft-deleted` is new) must be extracted into `locale/gitlab.pot` via `tooling/bin/gettext_extractor locale/gitlab.pot`. ## Out of scope - GraphQL mutation (`Mutations::Organizations::Restore`) — https://gitlab.com/gitlab-org/gitlab/-/work_items/599344+. - Admin Area UI / button to trigger restore — separate issue. ## Acceptance criteria - [ ] `Organizations::RestoreService#execute` transitions a `soft_deleted` organization to `active`. - [ ] Restore is authorized only for admins via the new `:restore_organization` ability. - [ ] Soft-deletion metadata (`soft_deleted_at`, `soft_deletion_scheduled_by_user_id`) is cleared on restore (handled by the existing `clear_soft_deletion_data` callback). - [ ] Attempting to restore a non-`soft_deleted` organization returns a `ServiceResponse` error. - [ ] The restore action is logged with the acting user and organization context. - [ ] Service spec covers authorization, state validation, successful transition, and logging.