Improve group transfer url assertion

What does this MR do and why?

Related to gitlab-org/quality/quality-engineering/team-tasks#1546 (closed)

The URL assertion in the group transfer specs was reloading the model after transfer and then checking comparing the path to the URL. This means we weren't checking that the path stayed the same. This MR saves the path before transfer and then checks that the path is kept the same but moved to a different namespace.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

bin/rspec spec/features/groups/group_settings_spec.rb

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

changed milestone to %15.11

added backend devopsdata stores grouptenant scale maintenancetest-gap typemaintenance labels

assigned to @peterhegman

added sectioncore platform label

	1 Message
	CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, add the Changelog trailer to the commit message you want to add to the changelog. If you want to create a changelog entry for GitLab EE, also add the EE: true trailer to your commit message. If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.

Reviewer roulette

Changes that require review have been detected!

Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:

Category	Reviewer	Maintainer
test for spec/features/*	Alina Mihaila (@alinamihaila) (UTC+3, 10 hours ahead of @peterhegman)	Maintainer review is optional for test for spec/features/*

To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed

@alinamihaila can you help review this when you have time?

requested review from @alinamihaila

mentioned in issue gitlab-org/quality/quality-engineering/team-tasks#1546 (closed)

approved this merge request

requested review from @sliaquat and removed review request for @alinamihaila

@alinamihaila, thanks for approving this merge request.

This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.

For more info, please refer to the following links:

• rspec predictive jobs
• jest predictive jobs
• merging a merge request.

added pipeline:mr-approved label

resolved all threads

approved this merge request

enabled an automatic merge when the pipeline for a0f3d141 succeeds

merged

mentioned in commit 2aa6ae85

added workflowstaging-canary label

added workflowcanary label and removed workflowstaging-canary label

added workflowstaging label and removed workflowcanary label

added workflowproduction label and removed workflowstaging label

added workflowpost-deploy-db-staging label and removed workflowproduction label

added workflowpost-deploy-db-production label and removed workflowpost-deploy-db-staging label

added releasedcandidate label

added releasedpublished label and removed releasedcandidate label