Route an already-activated owner off the Artifact Registry setup page

Narendranrequested to merge
nkannan/ar-619522-setup-page-conflict-state into master

What does this MR do and why?

artifactRegistryActivate refuses a claim from an organization that is already activated under another handle and returns the claimed registry alongside the refusal (!258132 (merged), merged). That refusal only comes from a stale setup page: one loaded before the organization was activated elsewhere, in another tab or by another owner. Today the setup page renders it against the handle field like any other refusal, which asks the owner to fix a field nothing can fix.

This MR implements the design the design review proposed and monolith/S10 criterion 34 now specifies (gitlab-org/ops/artifact-registry!3177 (merged), merged):

  • setup_form.vue — a refusal that still carries a registry is this case; the form emits conflict with the registry instead of rendering the error against the field, and stays busy like on success.
  • setup/app.vue — on conflict, reloads the page's own URL (the slug-less landing route) through refreshCurrentPageWithAlerts, carrying a dismissible informational banner. The organization has a mapping row by then, so the server answers the reload from the registry's state as it does for any activated organization: Repositories while the registry serves reads, the landing route's own state otherwise. The page keeps no status rule of its own.
  • Banner copy, per the copy note: Artifact registry is already enabled / Your organization is using the handle <handle>. The handle you entered was not claimed. It names only the claimed handle; the submitted one is never shown.
  • locale/gitlab.pot — two new strings.

Unchanged: a different-handle claim that overlaps the activating one still gets AR's 409 inline under the handle field (that refusal carries no registry, which is what tells the two apart). The mutation contract is unchanged. The status-routing constant and link from the earlier revision are gone with the status rule they served.

Tests

  • Jest: setup_form_spec keeps the four conflict examples (emits the registry, no success, nothing against the field, stays busy). app_spec asserts the exact refreshCurrentPageWithAlerts call for an active and a disabled registry (criterion 34's read-serving and non-read-serving cases) and that nothing else navigates.
  • RSpec :js (ee/spec/features/artifact_registry/setup_spec.rb): the read-serving half of criterion 34. An owner on the setup page, the organization activated after load, submits another handle; the page lands on the repositories route with the banner, the submitted handle appears nowhere, and a reload shows the banner no more. The non-read-serving half waits on the landing route's informational state (#623320), as the spec notes.

No changelog: artifact_registry_ui is default_enabled: false. No new GraphQL field or argument is consumed.

References

Screenshots or screen recordings

Captured from the new :js feature case (real browser, client faked at the model seam). The organization was activated as gdk after the page loaded; the owner then submits stale-tab-handle.

Stale setup page, before submit After submit: landing-route reload lands on Repositories with the banner
stale setup page repositories with banner

Previously this refusal rendered under the handle field ("Artifact Registry is already activated for this organization with the handle 'gdk'.") with the form left editable.

How to set up and validate locally

  1. Run the specs:

    yarn jest ee/spec/frontend/packages_and_registries/artifact_registry/setup/
bin/rspec ee/spec/features/artifact_registry/setup_spec.rb

  2. In GDK with artifact_registry_ui enabled and an organization with one top-level group and no registry, open the setup page in two tabs. Claim a handle in the first. In the second, submit a different handle.

  3. Expect the second tab to land on the registry's repositories with the banner above, naming the handle the first tab claimed. Reload: the banner is gone.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Narendran

Merge request reports