Danger Dialog

The DangerDialog is used to direct the user's attention towards a potentially destructive, non-reversible action such as deletion.

There are two variants:

1. Danger Confirmation requires an addition interaction from the user (i.e, checking a checkbox) in addition to a visual and text warning before they are able to confirm the action
2. Danger Warning simply presents the user with a visual and text warning before they confirm the action

The dialog aims to reduce cases of accidental deletion that may result from the browser "Are you sure?" confirmation dialog not sufficiently conveying the potential risks of a particular user action.

The DangerDialog is related to the FeedbackDialog, sharing some common behavior.

Overview

Anatomy

The FeedbackDialog is a variation of FeedbackDialog. It consists of:

• A red warning icon
• A title: a short description of the dialog action. This should be written in a neutral tone. The title is currently only used for accessibility purposes. Examples:
  • "Delete work package"
  • "Delete project"
• A heading: a question inviting the user to take a decision, This should be written in an active tone. You may also to give the full descriptive name of the resource on which the action will take place (e.g. "meeting occurrence" rather than just "meeting"). Examples:
  • "Permanently delete this work package?"
  • "Cancel this meeting occurrence?"
• A message explaining the consequences
• An additional content slot
• (For the Danger Confirmation) A confirmation checkbox with text: "I understand that this deletion cannot be reversed"
• Footer actions: "Cancel" and "Delete" (danger red)

For the Danger Confirmation, the primary button text is "Delete permanently" and it is disabled until the user checks the confirmation checkbox.

The button text can be customized if the dialog action is not a deletion.

The additional content area can be replaced with other options, such as different text, a list of work packages or additional interaction.

Options

Some elements can be customised:

• The heading text
• The contents of the content slot
• The text of the confirmation checkbox
• The texts of the footer action buttons

If you need a variant with a different structure, please contact the UX and Front-end Primer teams.

Best practices

Do:

• Do give the user relevant detail possible. For example, when bulk deleting, list the work packages that will be deleted. If the relevant details are too detailed (for example, there are over 10 work packages to be deleted), provide a summary instead of listing all individual items.
• Do use the simplest variant that will do the job, usually the default with customised text tailored to the specific context. Only choose variations or add additional elements if absolutely required.

Don't:

• Don't overload the content slot with too much information or additional interactions; we want the user to read and understand the consequences of this action. If the context that is needed is particularly complicated, consult the Design team for help on how to proceed.
• Don't use it to provide feedback. Use the FeedbackDialog instead.
• Don't add additional margins or spacing.
• Don't change the danger icon

Used in

The DangerDialog will replace the traditional Rails danger zone area in at least these places:

• work_packages: bulk/destroyusers: deletion
• repositories: destroy
• projects: change identifier
• placeholder_users: deletion
• projects: destroy
• storages: destroy
• openid_connect: destroy
• ldapgroups/synchronizedfilters: destroy
• ldapgroups/synchronizedgroups: destroy
• saml/providers: destroy
• Deleting a meeting series

The DangerDialog should also be used where we are currently using browser dialogs or a non-Primer modal for high-risk operations, such as:

• Bulk deleting work packages
• Deleting a custom field

The Danger Warning dialog should replace the default browser native "Are you sure?" dialog if the action is destructive and non reversible, for example:

• Deleting work packages
• Deleting individual meetings (or individual occurrences of a meeting series)
• Deleting a custom field
• Deleting a custom action
• Deleting a wiki

Technical notes

• In order to actually delete some object, you will most likely need a form which the "delete" button then submits. We have two ways to achieve that:
  • (With form_arguments)
  • (With a form builder)