Confirmation dialogs

mentioned in merge request !9519 (merged)

Thanks @hazelyang! Would you be able to compile a list of all these types of modals so we can update them all to the new design? I think the first step is to determine all the places we currently use the system alert. Maybe @filipa can help with that by checking the code.

We also probably want to change the wording of the buttons because Cancel pipeline and Cancel could be confusing. There should be only one button that represents canceling. Perhaps we change Cancel pipeline to Stop pipeline, along with the tooltip.

added ~19173 frontend feature proposal labels

changed title from Confirmation dialog for canceling pipeline to Confirmation dialogs

Would you be able to compile a list of all these types of modals so we can update them all to the new design?

@tauriedavis Sure. Updated on the issue description.

@tauriedavis @filipa If you find something I missed, please let me know. Thanks.

We also probably want to change the wording of the buttons because Cancel pipeline and Cancel could be confusing. There should be only one button that represents canceling. Perhaps we change Cancel pipeline to Stop pipeline, along with the tooltip.

Agreed with you. Updated.

Love the design @hazelyang!

I suggest the following changes in the text:

Deleting a user admin area/overview/users - I believe this won't happen anymore, correct @DouweM? We need to update the text once it's merged :)
I believe project/repository/branches(merged) and project/repository/branches are swapped
project/issues/labels Consider the text: "Are you sure you want to delete this label?"

The text we already have seems a little more user friendly than the proposed one, in this cases:

project/settings/members
project/issues/tags
project/wiki/page
project/issues/milestones

I would consider making the titles of the confirm boxes merely informative and not a question. I believe it's what most users are used to. :)

@filipa Thanks! I updated the text and labeled them "(updated)".

I believe project/repository/branches(merged) and project/repository/branches are swapped

Thanks! I changed them.

project/issues/labels Consider the text: "Are you sure you want to delete this label?"

I am wondering if we can drop "Are you are you want to". My reason is the text will look simple and direct.

I would consider making the titles of the confirm boxes merely informative and not a question. I believe it's what most users are used to. :)

Do you mean the text like "Remove group GitLab Org?" that includes a specific information(GitLab Org) for the confirmation?

List

Path	Screenshot	Proposal
`pipelines/`
`admin area/overview/projects`
`admin area/overview/users`
`admin area/overview/groups`
`admin area/overview/jobs`
`project/settings/members`
`project/repository/branches` (updated)
`project/repository/branches(merged)` (updated)
`project/issues/labels`(updated)
`project/issues/milestones`(updated)
`project/issues/tags` (updated)
`project/wiki/page` (updated)

Thank you @hazelyang. They look good to me!

@hazelyang nice designs!

Is there any UX guide for how wide a modal should be?
How well do these modals work on mobile?

@dimitrieh Thanks!

Is there any UX guide for how wide a modal should be?

I don't remember we have the guide for the modal...so I have the wide 540px for this modal. I am thinking if we also need to define the tone or writing style for something like dialogs. (But maybe need writing expert's help)

How well do these modals work on mobile?

Thanks for the reminder!

cc: @axil :)

@hazelyang i do think we can put the buttons on 1 line if the wording is short enough :) also i think the header can be decreased in height for smaller viewports.. it also increases its aesthetics.

@hazelyang would you mind adding what makes sense to you to the handbook? like when to use which width, writing style (@axil), placement of buttons on mobile, when a modal should be used and when not to... etc

I have a couple notes:

The header has a lot of white space above it with the x on it's own line. Is this necessary?
Destruction buttons should be clear and always say what they are destroying. Ex. Delete page instead of Delete
If the copy describes another action the user can take instead of the destructive one, I think we should provide a way for them to do that as a secondary button.
We should avoid the word cancel or canceled in the descriptive copy. It can be confusing when you then see the Cancel button. For the pipelines example, we can say that the pipeline will be stopped instead.
Some of the mockups above have the wrong copy. They are using the copy for stopping a pipeline but the title doesn't match.
Just some other general copy tweaks below.

Pipelines: There is copy about retrying and a retry button but there is no retry button.

Stop pipeline #33

Pipeline #33 will be stopped. You can retry the pipeline, instead, by clicking the retry button.

[Stop pipeline] [Retry pipeline]    [Cancel]

Admin projects: Copy fixes

Remove project [Project name]

You are going to remove this project. Removed projects **cannot** be restored.

[Remove project]     [Cancel]

Admin users: Copy fixes

Delete [Name]

All issues, merge requests, and groups link to the user [Name] will be removed. Consider blocking the user instead.

[Delete user] [Block user]     [Cancel]

Groups: This mockup looks like it has copy from pipelines. It needs to be updated to use copy for removing a group.

Remove group [Group name]

You are going to remove this group. Removed groups **cannot** be restored.

[Remove group]     [Cancel]

Jobs: This mockup also has the copy from pipelines. It needs to be updated to use copy for canceling jobs.

Stop all jobs

Stopping all jobs will halt all current jobs that are running.

[Stop jobs]    [Cancel]

Members: Copy tweaks

Remove [Name]

Removing [Name] will mean they are no longer a member of [Project].

[Remove user]     [Cancel]

Branches: Copy tweaks

Delete branch

Deleting branch [Branch name] **cannot** be undone.

[Delete branch]     [Cancel]

Delete merged branches: Copy tweaks

Delete all merged branches

Deleting all merged branches **cannot** be undone.

[Delete merged branches]     [Cancel]

Remove label: Copy tweaks

Remove label [Label]

Removing the label [Label name] will delete it from [Project name].

[Remove label]     [Cancel]

Remove milestone: Copy tweaks

Remove milestone [Milestone #]

Removing milestone [Milestone #] from [Project] **cannot** be undone.

[Remove milestone]     [Cancel]

Delete tag: Copy tweaks

Delete tag [Tag name]

Deleting tag [Tag name] from [Project] **cannot** be undone.

[Delete tag]     [Cancel]

Delete page: Copy tweaks

Delete page [page name]

Deleting the page [Page name] from [Project] **cannot** be undone.

[Delete page]     [Cancel]

Also totally agree about adding guidelines to the ux guide

@tauriedavis @dimitrieh Thanks!

I cut the white space between x and the text in the header. Looks much better. I also tried putting the x and the text in the same line, but it doesn't look good...

Once we decide the look of the modal, I'll update the copy in each modal in the description.

i do think we can put the buttons on 1 line if the wording is short enough :)

@dimitrieh I am ok with putting the buttons on 1 line. But we have 3 buttons sometimes now. Maybe...we still stack the buttons like the early design. What do you think?

would you mind adding what makes sense to you to the handbook? like when to use which width, writing style (@axil), placement of buttons on mobile, when a modal should be used and when not to... etc

Sure.

Thanks @hazelyang! Do you think it looks weird to have more padding on top than bottom of the header? Is there a way to make them equal that doesn't look strange with the close icon?

Other than that it looks great! Let's add the updates to the description!

@tauriedavis I tried putting the x and the text in the same line again. I have the padding on top and bottom be 24px this time. I think it works well and looks balanced visually. What do you think?

Short text in the header

Longer text in the header

Looks great! Thanks!

Updated the mockups with the new copy in the description!

mentioned in merge request !9833 (merged)

Nice! @tauriedavis I like your suggestions in https://gitlab.com/gitlab-org/gitlab-ce/issues/28849#note_24884869, so I turned them in guidelines https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9833.

I've got a couple of nitpicks:

Regarding the dialogs themselves, I see that in some cases we refer to the item in the header, for example Remove [Project], whereas this is specifically missing in the branch copy. Maybe that was not intentional. cc @tauriedavis

I'd like to see more consistency, so I'd propose to start all descriptions with You are about to [action]. If there is something else to add, add it in a new sentence. For example:

Remove milestone [Milestone #]

Removing milestone [Milestone #] from [Project] **cannot** be undone.

[Remove milestone]     [Cancel]

becomes:

Remove milestone [Milestone #]

You are about to remove milestone [Milestone #] from [Project]. This action **cannot** be undone.

[Remove milestone]     [Cancel]

Also, we should decide whether to repeat the action item inside the description as well. In some cases above we do, in others we don't. For example:
```
Remove group [Group name]

You are going to remove this group. Removed groups **cannot** be restored.

[Remove group]     [Cancel]
```

I agree @axil! Thanks for those and for documenting! :D

I don't think its a good use of time to keep updating all the mockups. The design is the same for each modal so instead, I added the main design to the issue description and the copy for each dialog box can be found in the table. This way @hazelyang doesn't have to keep updating mockups whenever copy changes and developers can copy/paste the text.

@hazelyang Maybe we should update just the mockup that is in the description so the copy is correct? That way people aren't confused by the mockup vs. the copy in the table.

Thanks! @tauriedavis @axil Updated the mockups in the description.

Great!

removed assignee

mentioned in issue #18083 (closed)

Specifically about the group or project deletion confirmation modal, I've shared a few improvements in https://gitlab.com/gitlab-org/gitlab-ce/issues/18083 that I think should be considered for this issue as well:

Add a “Cancel” button

Rephrase the modal title as a question, to which there are two answers: “Cancel” or “Delete”

Re-order the action buttons and align them to the left, to follow reading direction and OS's design best practices

Remove danger color from the explanation text and rephrase it so it doesn't look like it's screaming at you

Highlight key information in the explanatory text

Add a label to the input field

Removing vs Deleting: It's very important to differentiate between removing and deleting. Almost every remove action on this issue should be delete (except removing a project member). Per the UX guide:

Delete: Permanently remove an [item] from the system. Don’t use Remove Remove: Remove the association an [item] with [another] item or a list of items. Don’t use Delete

Confirmation input: I'd argue that some deletions are more critical than others. For example, deleting a project can have more negative impact than deleting a milestone. So, for project and groups, I suggest having a confirmation input where users need to type in the name of the object being deleted (like the image above). Also, deleting a specific branch that hasn't been merged should also have a confirmation input.

@hazelyang what do you think?

@pedroms Looks great to me!

@hazelyang Can you update the description with @pedroms' suggestions that you feel make sense for each dialog? And if there is an additional design for confirmation inputs, we should add that design to the description as well.

Thanks! @pedroms @tauriedavis I updated the issue description.

@hazelyang cool, thanks!

Suggestion: In the General confirmation dialog, if there are 3 action buttons, I think the actions should all be aligned to the ~~left~~ right, like: ~~Primary action, secondary action, dismissive action~~ Dismissive action, secondary action, primary action. This keeps all actions together and helps users scan the available options. What do you think?

Some copy tweaks to make it clearer and simpler:

You’re are about to delete this [project|group|branch|all merged branches|user|tag|label|milestone|page] [Object ID/name] …
Stop pipeline [Pipeline #]?: … You can retry pipeline [Pipeline number], instead, by clicking the retry button. To retry the pipeline instead, press Retry pipeline.
Delete [project|group] [Project name|Group name]?: … Once you confirm, all of this [project|group]’s data will be permanently deleted. Deleting the [project|group] [Project name|Group name] This cannot be restoredundone.
Delete user [User name]?: … Once you confirm, all issues, merge requests, and groups linked to the user [Name] this user will also be removeddeleted. This cannotbe undone. …
DeleteRemove member [Name]?: You’re are about to deleteremove [User name] from the members of project [Project name]. Removing [Name] will mean they are no longer a member of [Project]. Once you confirm, this user may no longer have access to the whole project or some parts of it. You can always re-add them as a member of this project if you want.

Let me know what you think. If you want I can change them in the description.

Edit: I meant to write “right-aligned buttons” instead of “left-aligned”.

@pedroms Thanks for your suggestion!

Suggestion: In the General confirmation dialog, if there are 3 action buttons, I think the actions should all be aligned to the left, like: Primary action, secondary action, dismissive action. This keeps all actions together and helps users scan the available options. What do you think?

I am a little not sure if all action buttons are aligned to the left is a good way. If the dismissive action and secondary action have the same button style and we put them together(A), it might be harder to differ them at a glance and be easier to cause the accidental error (for example: originally want to click "Cancel" but accidentally click "Retry pipeline"). I think if we separated these 2 buttons (B), the accidental error can be prevented in advance.

A	B

Another idea for the position of 3 buttons:

If there are three buttons, if "Cancel" is placed on the most left side would be better. When looking at the modal, people can quickly find "Cancel". The confirmation dialog is for preventing user from making irreversible mistakes, I think "Cancel" button is important and should be quickly recognized. And putting it on the left-bottom corner would make it be prominent since we are reading from left.

However, if there are only 2 buttons, "Cance" is still next to the primary button.

@pedroms What do you think?

@pedroms I updated the copy. Thanks!!

From our UX guide:

When there are a group of buttons in a dialog or a form, we need to be consistent with the placement.

Dismissive actions on the left

The dismissive action returns the user to the previous state.

Example: Cancel

Affirmative actions on the right

Affirmative actions continue to progress towards the user goal that triggered the dialog or form.

Example: Submit, Ok, Delete

This matches this mockup:

If there are only buttons, the dismissive button (Cancel) would still be on the left. And the affirmative button (Delete project) would be on the right.

The issue we are having is that the rest of GitLab has not been updated to reflect this guideline we have in the UX guide. Currently we use the opposite, with affirmative actions on the left and dismissive icons on the right.

So in the above examples the order would be:

Stop pipeline, Retry pipeline | Cancel

Delete project | Cancel

This is the order that is listed in the issue description because it is what matches the way GitLab currently places buttons. I also believe this is what Pedro is suggesting.

We have an issue to fix the placement: https://gitlab.com/gitlab-org/gitlab-ce/issues/26248

mentioned in issue #26248 (moved)

This is the order that is listed in the issue description because it is what matches the way GitLab currently places buttons. I also believe this is what Pedro is suggesting.

@tauriedavis @hazelyang Sorry, what I meant to say was right-align the buttons, not left-aligned, in the case of confirmation dialogs (used for destructive actions). I've laid out my rationale at https://gitlab.com/gitlab-org/gitlab-ce/issues/26248#note_26082532

So, in this case, the buttons all would be right-aligned, ordered from Dismissive > Affirmative: Cancel, Retry pipeline, Stop pipeline.

Regarding the dialog boxes proposal in the list above I would like to add that the large visual separation between the buttons makes comparing actions more difficult. The following paragraph of this article gives some explanations:

Place the buttons in the corners, or keep them together? [...] The danger of placing the ‘Cancel’ button in the far left corner is that it can cause users to overlook it due to the large visual separation between the two buttons. Putting the ‘Cancel’ button together with the ‘Ok’ button makes it easier for users to see both buttons. This allows users to efficiently compare the two actions in a single gaze to choose the best action to take.

@kwad Exactly, I agree. No matter the alignment, actions should stay together.

mentioned in issue #30606 (moved)

@pedroms @kwad Thanks for your feedback! I updated the issue description.

@hazelyang looking at the description it says: “Re-order the action buttons and align them to the left”. Wouldn't that be align them to the right? Also, the table column says “New Buttons (left to right)”. I suppose that's also the other way around?

@pedroms Oops, the table was my fault. I added that and mixed up left/right :slap_forehead: I fixed it and the description as well.

@tauriedavis no problem, glad we caught it before anyone implemented it

@tauriedavis @pedroms Thanks!

@hazelyang take a look at the confirmation modal in the description of https://gitlab.com/gitlab-org/gitlab-ce/issues/21393 to delete a protected branch. Some things I think we could pick from there:

“You're about to permanently delete” — emphasizes that it is unrecoverable
“This branch hasn’t been merged yet. To avoid data loss, consider merging this branch into another before deleting it. — this is helpful for any kind of branches, protected or not
“Once you confirm, this cannot be undone and press Delete protected branch, it cannot be undone or recovered.” — clarifies the steps (input and then button) and emphasizes the unrecoverable state

What do you think?

Those are nice improvements. Can we apply them to all of the dialogs in the description? I esp. like adding "permanently" in cases where that applies.

@tauriedavis @hazelyang I've updated the description with the suggestions made at https://gitlab.com/gitlab-org/gitlab-ce/issues/28849#note_27733104

@timzallmann can you assess the workload of the ~Frontend team to schedule this for a next release? Thanks

mentioned in issue #13482 (closed)

mentioned in issue #30034 (moved)

assigned to @timzallmann

mentioned in issue #32295 (closed)

mentioned in issue #33378 (moved)

added Accepting Merge Requests label

mentioned in issue #27464 (moved)

mentioned in merge request !12569 (merged)

mentioned in issue #35721 (closed)

mentioned in issue #31890 (closed)

mentioned in merge request !13691 (merged)

mentioned in issue #36888

For the modals, should the objects be linkable? For example, if you refer to Pipeline #33 in the dialog, shouldn't you be able to click on it and GitLab navigates you to that pipeline page? Is there some UI rule for/against this type of design?
If we allow links in the dialog, should it appear in the body and/or the title of the dialog?
Should labels be styled/formatted similarly as in system notes? Should it be styled as a label with the pill and color in the dialog box itself. (I think all other objects are just text.)

So for example,

Delete Discussion ?
You’re about to permanently delete Discussion from this group, its subgroups, and projects, and remove it from [Issue and merge request count] issues and merge requests. Once deleted, it cannot be undone or recovered.

changed the description

For the modals, should the objects be linkable? For example, if you refer to Pipeline #33 in the dialog, shouldn't you be able to click on it and GitLab navigates you to that pipeline page? Is there some UI rule for/against this type of design?

If we allow links in the dialog, should it appear in the body and/or the title of the dialog?

I don't think they need to be linkable in these cases. The confirmation pops up over the object it is mentioning. Closing the model will show the object.

As a counter example: I mentioned adding links in this MR, because the title would link out to a different page.

Should labels be styled/formatted similarly as in system notes? Should it be styled as a label with the pill and color in the dialog box itself. (I think all other objects are just text.)

Sure, I added this to the description.

Thanks @tauriedavis . @hazelyang : Please confirm the design change, and we can use it here! https://gitlab.com/gitlab-org/gitlab-ce/issues/36888.

changed the description

Updated the description:

include the use of monospaced font for Git refs.
for branch confirmation, clarify that branches haven't been merged to the default branch (see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14220#note_40242132 for context)

mentioned in issue #38165

marked this issue as related to #38165

Is this all going to be covered at once or should we split these proposals into separately actionable issues and open label Accepting Merge Requests ? I think that these would be quickly picked up by the community if we broke the tasks out.

Is this all going to be covered at once

@markglenfletcher We have already started implementing modals one by one as Deliverable . I'm not sure if that will continue.

should we split these proposals into separately actionable issues

I'm not sure if splitting into issues is necessary but I would at least split them into separate merge request and maybe add a task list to the description of this issue.

and open label Accepting Merge Requests

I think it would be a good idea to have documentation about the implementation first, so we don't struggle with 10 different variants afterwards. The new repo editor has added a Vue component that I'm extending in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14360. I was planning to add a storybook to be able to try out different uses (https://gitlab.com/gitlab-org/gitlab-ce/issues/37699) but I'm not sure if this will be ready with 10.1.

Having said that, Accepting Merge Requests was already added, so maybe we should remove it until we have decided on the plan?

I think if frontend is putting work into this, we should remove Accepting Merge Requests right now. If frontend feels it is in a place for others to contribute, we can add it back.

removed Accepting Merge Requests label

mentioned in issue #37808

mentioned in issue #38606

moved to gitlab#8561

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue

Path	New Title	New Description	New Buttons
`pipelines/`	Stop pipeline ‘#[Pipeline ID]’?	You’re about to stop pipeline #[Pipeline ID]. To retry this pipeline instead, press Retry pipeline.	[Cancel] [Retry pipeline] [Stop pipeline]
`admin area/overview/projects`	Delete project ‘[Project name]’?	You’re about to permanently delete the project [Project name], its repository, and all related resources including issues, merge requests, etc.. Once you confirm and press Delete project, it cannot be undone or recovered. To confirm, type `[Project name]`	[Cancel] [Delete project]
`admin area/overview/users`	Delete user ‘[User name]’?	You’re about to permanently delete the user [User name], and all of the issues, merge requests, and groups linked to them. To avoid data loss, consider blocking this user instead, by pressing Block user. Once you confirm and press Delete user, it cannot be undone or recovered. To confirm, type `[User name]`	[Cancel] [Block user] [Delete user]
`admin area/overview/groups`	Delete group ‘[Group name]’?	You’re about to permanently delete the group [Group name], its subgroups, projects, repositories, and all related resources including issues, merge requests, etc.. Once you confirm and press Delete group, it cannot be undone or recovered. To confirm, type `[Group name]`	[Cancel] [Delete group]
`admin area/overview/jobs`	Stop all jobs?	You’re about to stop all jobs. This will halt all current jobs that are running.	[Cancel] [Stop jobs]
`project/settings/members`	Remove member ‘[User name]’?	You’re about to remove the user [User name] from the members of project [Project name]. Once you remove them, they may still have access to some parts of this project. You can always re-add them as a member of this project if you want.	[Cancel] [Remove user]
`project/repository/branches`	Delete branch ‘[Branch name]’?	You’re about to permanently delete the branch [Branch name]. This branch hasn’t been merged into ‘[Default branch name]’. To avoid data loss, consider merging this branch before deleting it. Once you confirm and press Delete branch, it cannot be undone or recovered. To confirm, type `[Branch name]`	[Cancel] [Delete branch]
`project/repository/branches(merged)`	Delete all merged branches?	You’re about to permanently delete [Branch count] branches that were merged into ‘[Default branch name]’. Once you confirm and press Delete merged branches, it cannot be undone or recovered. To confirm, type `[Branch count] branches`	[Cancel] [Delete merged branches]
`group/issues/labels`	Delete label ‘[Label name]’?	You’re about to permanently delete the label [Label name] from this group, its subgroups, and projects, and remove it from [Issue and merge request count] issues and merge requests. Once deleted, it cannot be undone or recovered.	[Cancel] [Delete label]
`project/issues/labels`	Delete label ‘[Label name]’?	You’re about to permanently delete the label [Label name] from this project and remove it from [Issue and merge request count] issues and merge requests. Once deleted, it cannot be undone or recovered.	[Cancel] [Delete label]
`project/issues/milestones`	Delete milestone ‘[Milestone name]’?	You’re about to permanently delete the milestone [Milestone name] from this project and remove it from [Issue and merge request count] issues and merge requests. Once deleted, it cannot be undone or recovered.	[Cancel] [Delete milestone]
`project/repository/tags`	Delete tag ‘[Tag name]’?	You’re about to permanently delete the tag [Tag name]. Once deleted, it cannot be undone or recovered.	[Cancel] [Delete tag]
`project/wiki/page`	Delete page ‘[Page name]’?	You’re about to permanently delete the page [Page name]. Once deleted, it cannot be undone or recovered.	[Cancel] [Delete page]

Confirmation dialogs

New design

General confirmation dialog

Special confirmation dialog: Deleting project / group / branch(that hasn't been merged)

Mobile

List and new copy

Designs

Child items ...

Activity

List

Short text in the header

Longer text in the header

Another idea for the position of 3 buttons:

When there are a group of buttons in a dialog or a form, we need to be consistent with the placement.

Dismissive actions on the left

Affirmative actions on the right

Frequently Asked Questions

Admin message

Admin message

Confirmation dialogs

New design

General confirmation dialog

Special confirmation dialog: Deleting project / group / branch(that hasn't been merged)

Mobile

List and new copy

Relates to

Activity

List

Short text in the header

Longer text in the header

Another idea for the position of 3 buttons:

When there are a group of buttons in a dialog or a form, we need to be consistent with the placement.

Dismissive actions on the left

Affirmative actions on the right

Frequently Asked Questions