Scope BulkImports::CreateService destination resolver to the request organization

What does this MR do and why?

The destination organization resolver in BulkImports::CreateService was doing a global Group.find_by_full_path(namespace) lookup, which could match a same-path group in a foreign organization and stamp the resulting BulkImport with that foreign org.

This scopes the lookup to fallback_organization.groups (already injected by both callers, set to Current.organization). If the path isn't found there, it falls through to fallback_organization as before. Net effect: a path collision in a foreign org no longer leaks into BulkImport.organization.

The merged !236603 (merged) only caught this when one side was isolated?. With this change, non-isolated orgs get the same protection. The organization(namespace) signature and return contract are unchanged, so validate_destination_organizations! keeps working as defense-in-depth for any future caller that bypasses the resolver.

Note to reviewers

A few cross-org test cases from !236603 (merged) were removed because the resolver now closes the leak before the validator runs, making those branches unreachable through the request path. The validator itself is unchanged and still guards against any caller that bypasses the resolver.

Screenshots or screen recordings

N/A — backend-only.

Before After

How to set up and validate locally

  1. Create two organizations and a group with the same path in each.
  2. As a user in org A, POST to /api/v4/bulk_imports with destination_namespace matching the path.
  3. Verify the created BulkImport is stamped with org A, not org B.

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.

References


Edited by Rez

Merge request reports

Loading
Loading