Allow more than 20 issues to be batch edited at once

Problem to solve

Currently, when bulk editing issues a maximum of 20 issues are displayed for selection at any one time. If more than 20 issues need to be edited, these need to be selected and edited in a separate step. This takes longer and introduces more risk of mistakes being made when large numbers of issues need to be edited.

Further details

Use case

Editing >20 issues at a time. Eg. I currently need to move 22 issues from 'testing' to 'closed'. Previously I had to re-label 47 issues, which had to be done in several steps.

Benefits

1. Speed. Currently it takes many clicks and delays to search for issues, select them, choose fields to update, apply the updates, then repeat this several times to complete the update over all needed issues.
2. Reduce errors. The first time I had to bulk update a number of issues, I mistakenly selected a different label to update after having completed updates on 40 issues. This led to the remaining issues being mis-filed, and much wasted time to update them correctly. These kinds of errors are more likely when many small steps have to be repeated over and over.

Proposal

Add a button at the bottom of the Issues - List page allowing more than 20 list items to be displayed. A warning can be displayed explaining that this may take longer due to extra processing. This would allow all required issues to be updated in a single step, with only a single delay for the extra processing required.

What does success look like, and how can we measure that?

I can select all issues in my project at once for a bulk update. If there are processing constraints, this could be set to a much higher limit of 500 or 1000 issues at once. (If no way to measure success, link to an issue that will implement a way to measure this)

Links / references

• issue gitlab-ce#33952 describes how to bulk move issues, but without reference to the 20 issue limit.

~"feature proposal"

changed title from Bulk editing of issues can be done for more than 20 issues at a time to Allow more than 20 issues to be batch edited at once

@manishdimensionsoftware Thanks for the proposal. There are other proposals to increase the paged number of results which would also solve this:

• https://gitlab.com/gitlab-org/gitlab-ce/issues/35312

added Plan [DEPRECATED] devopsplan issues merge requests typefeature labels

added Create [DEPRECATED] label

removed Create [DEPRECATED] merge requests labels

@ebrinkman we inadvertently added this with manual sorting. Manual sort lets you view 100 issues at once, and we don't forbid bulk editing (https://docs.gitlab.com/ee/user/project/bulk_editing.html) on that sort.

Do you think we should forbid that there? It may have performance issues if you update all 100 issues at once, but we could just let you do it and then address any performance issues that come up if that happens.

cc @digitalmoksha

Yes @smcgivern in the essence of iteration, let's forbid it there.

Just so I'm clear - during batch editing, we should disable manual sorting, until the batch editing mode is complete?

Once this issue is resolved (allowing the user to choose how many items to display at once), then I think we should be able to remove the artificial 100 item max for manual sorting and simply use whatever the user has chosen.

/cc @rajatgitlab

@ebrinkman @digitalmoksha I think the idea is to forbid batch editing when you're doing manual sorting, not the other way around? (You sort first, then edit.)

@ebrinkman @smcgivern I'm not sure that makes sense. Manual sorting is a sort style, just like by priority or updated date. But we allow you to change the order of items as you see fit. So you'll see people using that as their primary sort. And once you've got things in the order you want them, you'll want to batch edit them to change whatever. Switching "out" of manual sorting order to, say, updated date, means your list is not sorted the way you need it, and the items you want to edit are scattered around the list.

You could disable the actual drag/drop sorting while in batch mode, but that doesn't buy you anything. And suddenly dropping from displaying 100 items in our manual sort order mode to 20 just when we show the batch editing panel is counter intuitive.

I actually feel like we should leave the "100" limit as it is (it's already written and merged a couple weeks ago), and iterate on that. Which would seem to be allowing more than 20 items to be displayed at once across the issue lists, or some other iteration.

I like this approach @digitalmoksha.

How do you enable manual sorting? I have to bulk update ~1500 issues and doing it 100 at a time will drive me less crazy than 20 at a time.

@jlenny If you're self-hosting 12.0, you should be able to enable the feature flag manual_sorting. You wouldn't actually be able to manual sort (drag/drop), but it will increase the list size to 100 (and sort by the order set in boards, etc).

We don't have it enabled in GitLab.com yet. But as the frontend code was merged a couple days ago, I expect we should be able to enable it next week once it goes through our deploy pipeline.

You'll know it's on if you see Manual in the issue sort drop down

added [deprecated] Accepting merge requests label

added groupproject management label

removed [deprecated] Accepting merge requests label

added customer label

Premium customer with 6000 users is interested in this... https://gitlab.my.salesforce.com/00161000004bZPD?srPos=0&srKp=001

mentioned in issue #32503 (closed)

mentioned in issue #32978 (closed)

Gold customer interested in this feature - https://gitlab.my.salesforce.com/00161000004zrCF. cc @Larry-Gitlab

mentioned in issue #193031 (closed)

mentioned in issue #195103 (closed)

mentioned in issue #196467 (closed)

mentioned in issue #197801 (closed)

mentioned in issue #198984 (closed)

mentioned in issue #201640 (closed)

mentioned in issue #204656 (closed)

mentioned in issue #206820 (closed)

mentioned in issue #207756 (closed)

mentioned in issue #208619 (closed)

mentioned in issue #209702 (closed)

mentioned in issue #211278 (closed)

mentioned in issue #212102 (closed)

mentioned in issue #212794 (closed)

mentioned in issue #212807 (closed)

mentioned in issue #213483 (closed)

mentioned in issue #214175 (closed)

mentioned in issue #214945 (closed)

mentioned in issue #215811 (closed)

mentioned in issue #216406 (closed)

mentioned in issue #217265 (closed)

mentioned in issue #218184 (closed)

mentioned in issue #218926 (closed)

mentioned in issue #219679 (closed)

mentioned in issue #220713 (closed)

mentioned in issue #222213 (closed)

mentioned in issue #223632 (closed)

mentioned in issue #225113 (closed)

added UX debt label

changed milestone to %Backlog

@hollyreynolds i marked this as UX debt because it's super annoying to have to batch edit dozens of pages when you're just trying to bulk update a single field across N number of issues.

added [deprecated] Accepting merge requests label

added internal customer label

This would help the Technical Writing team bulk edit some labels that are on hundreds of MRs and issues. technical-writing#229

Without it, I believe we will need help from an engineer to do this.

mentioned in issue technical-writing#229

added sectiondev label

removed UX debt label

added featureenhancement label

removed featureenhancement label

@shoyle1 We're interested in this. We have a lot of bulk editing to do as a part of our transition and I imagine it will be part of our ongoing operations/governance as well. 20 at a time is a nightmare.

/cc @brian.lupson @saravanan.yoganandam

I have a GitLab Ultimate ~SaaS customer with 1700 users interested in this feature.

• Link to request: https://gitlab.my.salesforce.com/0016100001BQoSS
• Why interested: Why is this important to you? We have a lot of bulk editing to do as a part of our transition and I imagine it will be part of our ongoing operations/governance as well. 20 at a time is a nightmare.
• Current solution for this problem: none
• PM to mention: @gweaver

@josh.langley you'd need the help of a developer to get the policies set up, but https://gitlab.com/gitlab-org/gitlab-triage may be a viable workaround until we solve the "20 at a time" limit. We currently use gitlab-triage to handle bulk updating properties on issues and automating issue hygiene.

100 seat, Ultimate SaaS customer requesting this feature: https://gitlab.my.salesforce.com/0014M00001sE7De

Customer is trying to efficiently edit hundreds of issues. See the following for details, https://gitlab.com/gitlab-com/account-management/commercial/gosecure/-/issues/58.

/cc @gweaver

marked #300706 (closed) as a duplicate of this issue

marked this issue as related to #300706 (closed)

removed Plan [DEPRECATED] label

We're still missing this every day

still limited, but you can do 50 or 100 at a time now:

• ZD Ticket: https://gitlab.zendesk.com/agent/tickets/548856

Currently no way to bulk edit more than the 100 on the page. Would be great if we had a Select All button