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
- Create two organizations and a group with the same path in each.
- As a user in org A, POST to
/api/v4/bulk_importswithdestination_namespacematching the path. - Verify the created
BulkImportis 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
- Issue: #595673 (closed)
- Predecessor: !236603 (merged), shipped
validate_destination_organizations!and the resolver method this MR rewrites.