Update MR form to use plural field names

Issue #244835 (closed)

What does this MR do?

Pluralize Assignee and Reviewer in MR form

Testing Case

1. Go to a Merge Request and click "edit".

In the free tier, it will display the singular wording. In the paid tier, it will display the plural wording, irrespective of the size.

Paid ( <= 1)	Paid ( > 1)	Free

Note

This change will also affect the Issues form page. Example:

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Closes #244835 (closed)

Closes #244835 (closed)

changed milestone to %13.4

added devopscreate frontend groupsource code labels

@sming-gitlab I opened this myself because I thought it would be straightforward, but then I remembered that Core doesn't have multiple assignees! So it should read Assignee in Core and Assignees in Starter+ https://docs.gitlab.com/ee/user/project/merge_requests/getting_started.html#multiple-assignees-starter

Feel free to close or reuse this MR for your work.

added sectiondev label

changed milestone to %13.5

added missed:13.4 label

added 6403 commits

• 3566103a...5ac5c764 - 6402 commits from branch master
• 7bc7fe61 - Pluralize Assignee & Reviewers in MR Form

Compare with previous version

unmarked as a Work In Progress

assigned to @sming-gitlab

	1 Warning
	featureaddition and featureenhancement merge requests normally have a documentation change. Consider adding a documentation update or confirming the documentation plan with the Technical Writer counterpart. For more information, see: The Handbook page on throughput implementation. The definition of done documentation.

Reviewer roulette

Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.

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 the chosen person is unavailable.

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, mention them as you normally would! Danger does not automatically notify them for you.

Category	Reviewer	Maintainer
frontend	Tomas Vik (@viktomas) (UTC+1, 1 hour ahead of @pedroms)	Kushal Pandya (@kushalpandya) (UTC+5.5, 5.5 hours ahead of @pedroms)
test Quality for spec/features/*	Mark Lapierre (@mlapierre) (UTC+11, 11 hours ahead of @pedroms)	Maintainer review is optional for test Quality for spec/features/*

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

Generated by Danger

changed the description

Bundle size analysis [beta]

This compares changes in bundle size for entry points between the commits ac4588fe and 56754866

Special assets

Entrypoint / Name	Size before	Size after	Diff	Diff in percent
average	3.15 MB	3.15 MB	-	0.0 %
mainChunk	1.95 MB	1.95 MB	-	0.0 %

---

Please look at the full report for more details

---

Read more about how this report works.

Generated by Danger

changed the description

@farias-gl can you please review when you have time?

assigned to @farias-gl

added 249 commits

• 7bc7fe61...b18cdc7a - 248 commits from branch master
• bd9fa5b1 - Pluralize Assignee & Reviewers in MR Form

Compare with previous version

@sming-gitlab and @pedroms

I guess I'm a. bit confused on who to ping. I saw @pedroms opened the original MR but is @sming-gitlab owning the MR now?

Left some feedback either way

@sming-gitlab maybe I should have explained myself more clearly, but the intention here was to differentiate tiers where only one assignee/reviewer is allowed vs multiple assignees/reviewers. That's why I said in !41402 (comment 407006301):

So it should read Assignee in Core and Assignees in Starter+

1. Core: Assignee and Reviewer
2. Starter+: Assignees and Reviewers

So the pluralization of the field label is not dependent on the number of entries in that field, but rather on the what is allowed in that tier. So in Starter+, even if there are no assignees or just 1 assignee, the field label is Assignees because it allows for multiple assignees. Does that make sense?

changed title from Resolve "Update MR form to use plural field names" to Update MR form to use plural field names

changed the description

assigned to @pedroms and unassigned @farias-gl

added 839 commits

• bd9fa5b1...803d87fe - 837 commits from branch master
• b628860e - Pluralize Assignee & Reviewers in MR Form
• fcbc79fe - Plural form always for paid tiers

Compare with previous version

added 1 commit

• b6f81dc7 - Plural form always for paid tiers

Compare with previous version

@sming-gitlab did another review, but wasn't sure if you wanted one. I saw the pings, but please re-assign to me in the future to indicate future reviews.

Left some minor notes, but otherwise looks good!

unassigned @pedroms

added 1 commit

• 51cea8da - Plural form always for paid tiers

Compare with previous version

changed the description

mentioned in issue #267761 (closed)

added 340 commits

• 51cea8da...d6954c00 - 338 commits from branch master
• e5c8c620 - Pluralize Assignee & Reviewers in MR Form
• a8388f83 - Plural form always for paid tiers

Compare with previous version

added 1 commit

• f47db1e0 - Plural form always for paid tiers

Compare with previous version

added 1 commit

• 7277c84e - Plural form always for paid tiers

Compare with previous version

assigned to @farias-gl

mentioned in issue #268008 (closed)

unassigned @farias-gl

assigned to @jivanvl

@jivanvl thanks for letting me squeeze my MR into your schedule -- I know the last day of sprint is always hectic

added featureenhancement typefeature labels

Suggestion I'm not sure how the test team does this, but, I think it might be a good idea to create a follow up to add the missing rspec scenarios for when this feature flag is set to true

Perhaps this is worthy of sending for review with a backend or test engineer?

@jivanvl That's a good call! Yes, let's not rush this MR for this sprint then Let me add more feature specs for the scenario you suggested and then get the QA to review it. Will ping you once it's ready again! Thanks again for being so prompt on this review

changed this line in version 9 of the diff

@jivanvl Finally have time to get back to this MR I made a few tiny adjustments to the spec after reading our docs > https://docs.gitlab.com/ee/development/feature_flags/development.html#feature-flags-in-tests

It is strongly advised to test all code affected by a feature flag, both when enabled and disabled to ensure the feature works properly.

When using the testing environment, all feature flags are enabled by default.

So that means by default, our FF is enabled. So I should adjust the current test to suit this and then ADD a test when it is disabled. (This approach also makes more sense to me, cause we are future-proofing when the FE is enabled by default and then finally becoming the norm of our codebase).

Anyways, let me know if this approach makes sense, sending it back to you

@sming-gitlab That makes sense unfortunately without the feature flag this is causing a legitimate error in gitlab-foss, so I think it is necessary to have the feature flag set on and off. Also you have rubocop issue

Do let me know if you want to pair to try and address the spec failures looking pretty solid so far

@jivanvl I just realized this is a license thing NOT feature flag And I ended up returning to my original route. Although it passed locally, our pipeline seemed not to like it. I think it's because the spec is not inside the ee folder. So I created the ee related spec inside the ee directory. It's passing now, sending it back to you

Although it passed locally, our pipeline seemed not to like it

FYI this was because our pipeline runs both FOSS and non-FOSS environments. Your test passed on non-FOSS because the license exists there, but on FOSS there's no such thing as a license, and all the code inside ee doesn't even exist, so the flag check defaulted to false.

Moving this to the ee area was the right call

@mdelaossa OH, that's what it is Thanks for clearing that up for me!! Phew, luckily I made the right call, was really pulling my hair out on that one

unassigned @jivanvl

changed milestone to %13.6

approved this merge request

@sming-gitlab frontend looks good to me! Approved

Setting label(s) Category:Source Code Management based on groupsource code.

added Category:Source Code Management label

added 5803 commits

• 7277c84e...a42447df - 5800 commits from branch master
• 7cafc4e9 - Pluralize Assignee & Reviewers in MR Form
• 88262db8 - Plural form always for paid tiers
• 5bd3d3b2 - Adjust spec for FF scenario

Compare with previous version

added 186 commits

• 5bd3d3b2...7178e65a - 182 commits from branch master
• c2a1c875 - Pluralize Assignee & Reviewers in MR Form
• a8f38133 - Plural form always for paid tiers
• 3dc29b37 - Adjust spec for FF scenario
• f91de78c - Correct to use license not feature stub

Compare with previous version

added 1 commit

• fe7ec77d - Stub license to issue test

Compare with previous version

added 1 commit

• ebda160c - Flip stub license testing

Compare with previous version

added 1 commit

• 6b585416 - Flip stub license testing

Compare with previous version

added 1 commit

• 37805b12 - Flip stub license testing

Compare with previous version

added 1 commit

• 69c18291 - Create ee related spec

Compare with previous version

changed milestone to %13.7

added missed:13.6 label

added 164 commits

• 69c18291...f3a53fc2 - 157 commits from branch master
• 0e3758bb - Pluralize Assignee & Reviewers in MR Form
• fbd03b90 - Plural form always for paid tiers
• 53f14dfa - Adjust spec for FF scenario
• d0edd83b - Correct to use license not feature stub
• 4ed4bcb3 - Stub license to issue test
• 60f29fbb - Flip stub license testing
• 56754866 - Create ee related spec

Compare with previous version

assigned to @jivanvl

approved this merge request

frontend looks good to me! Assigning a backend reviewer to help us out with the RSpec tests and from there I can merge

@mdelaossa Can you please take a look?

assigned to @mdelaossa

approved this merge request

unassigned @mdelaossa

resolved all threads

Thanks @sming-gitlab this looks good to me!

enabled an automatic merge when the pipeline for 36f233ee succeeds

merged

mentioned in commit c0026bcf

added workflowstaging label

added workflowcanary label and removed workflowstaging label

added workflowproduction label and removed workflowcanary label

added releasedcandidate label

added releasedpublished label and removed releasedcandidate label

mentioned in issue #244835 (closed)

mentioned in issue thomasrandolph/todo#6 (closed)