## Problem statement We need to be able to disable write access to a given Organization while their migration (eg. to a Protocell) is in progress. This is **not** the same as instance-wide Maintenance Mode: the Organization's content (groups, projects, settings etc) should remain readable but not editable, with a banner indicating the Organization is in read-only mode. The design is formalized in [ADR 010: Organization Read-Only Mode](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/decisions/010_organization_read_only_mode/). In summary: * A per-Organization state on `Organizations::Stateful`: `active → read_only_initialization → read_only` (and back), with a `reason` recorded for audit (migration, isolation, incident, billing, legal) * Enforcement keyed off `Current.organization` at every write surface: controllers, REST API (Grape), GraphQL mutations, `Gitlab::GitAccess`, Container Registry, LFS, and Sidekiq * Org-scoped Sidekiq jobs drain; cron workers skip read-only Organizations; BBMs are paused on the source Cell * A cutover readiness contract gates the data-copy step on a fully drained source Cell * An authentication exemption keeps sign-in working (existing `users` row updates allowed; new `users` row creation blocked) The POC (gitlab-org/gitlab!228743) validated the approach and will not be merged; production implementation builds on the merged unified state machine (gitlab-org/gitlab!230909). ## Exit criteria * Write requests (web UI, GraphQL mutations, REST API, git push, registry push, LFS upload) to an Organization in `read_only_initialization` or `read_only` fail with a structured error (`503` + `Retry-After` for time-bounded reasons, `403` otherwise); reads continue to work * Authentication remains available; no new `users` rows are created for a read-only Organization * Org-scoped Sidekiq jobs drain and cron workers skip the read-only Organization, observable via structured logs * A cutover readiness check reports when the source Cell is fully drained for the Organization * New pipelines are blocked and in-flight CI jobs are cancelled on entering read-only * All pages owned by the Organization show a prominent read-only banner * Rollout is gated by environment- and Organization-scoped feature flags, default-off on Self-Managed/Dedicated <!-- STATUS NOTE START --> ## Status 2026-07-16 # Implement Organizations Read-Only Mode — Weekly Status Update *Container Registry enforcement and the Sidekiq design shipped; authentication protections need two final review threads before rollout.* ## 🕐 total hours spent this week by all contributors 20 ## 🎉 achievements * [!242755](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/242755) merged by @alejandro (2026-07-15), blocking Container Registry push and delete during read-only mode while preserving pull, behind the rollout flag. * [ADR 010 update !20345](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/20345) merged by @rutgerwessels (2026-07-14), standardizing Sidekiq on `Current.organization` and defining drain-aware worker and cron behavior. ## 🚫 blockers * [!243972](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243972) still has one unresolved identity-verification discussion after @mmacrae-bovell’s approval; resolve the thread before maintainer merge. * [!243952](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243952) awaits an `IdentityLinker` spec assertion requested by @hptrs; add coverage and resolve the discussion before maintainer merge. ## ▶️ next * Resolve remaining discussions on [!243972](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243972) and [!243952](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243952), then merge both authentication enforcement changes with passing pipelines. * Start [#605609](https://gitlab.com/gitlab-org/gitlab/-/work_items/605609) once both MRs merge, consolidating status policy, messages, logging, and cross-surface tests. * Begin [#603377](https://gitlab.com/gitlab-org/gitlab/-/work_items/603377) internal-organization rollout after authentication enforcement lands, then monitor blocked-write logs before expanding cohorts. * Keep syncing with @rutgerwessels on [#599101](https://gitlab.com/gitlab-org/gitlab/-/work_items/599101) to define per-iteration organization context for cron workers that mutate organization-owned data. _Copied from https://gitlab.com/groups/gitlab-org/-/epics/20404#note_3564264879_ <!-- STATUS NOTE END -->