Proposals are coloured.

Security is not only about protection from malicious actors. We also need protection from "friendly fire": Well-meaning users who make mistakes. Case in point: Sometimes users delete content they didn't intend to delete. We can avoid this by UI improvements, default permission setup, permission recipies, etc.

Some content/stuff we should be careful about deleting:

• Content with children
• Content with relations
• Important/top level content
• Users/User groups
• Roles/Policies
• Sections
• Object states

Approaches

• Those who have, and must keep access should be warned
• Those who don't need this access should be blocked, and UI features should be disabled

This affects not only content view, but also content edit, as well as role/policy views.

We can add more key information to content views (see Ramzi feature for relations labels). This gives the user more information before the delete dialog pops up, so they are expecting it. There should be "more info" available for the inexperienced user about what this means and what could go wrong.

We have a confirmation dialog for deleting content, this shows a checkbox if the content has children. You have to check this to be able to delete. This should be extended to also have checkboxes in case of (reverse) related content, or other cases. So 3 new checkboxes are relevant now: Related content, reverse related content, and image asssets.

How should the bulk delete dialog reflect this? This is difficult both in UI and for performance. TODO

For deleting roles and policies there should always be warning dialogs. We have this now, but they could have more information about the risk.

There is also a proposal to use object states to mark certain content as "Important". This can be used with policies to deny delete access, without any development. Could be a doc recipe, or we could include this change in our default content. (With some development we could also let this affect the delete dialog, but this is hackish/arbitrary.)

A plain eZ Platform install has these user groups by default:

• Anonymous
• Administrators
• Editors (empty)
• Guest accounts (empty)

We propose to add a new group ("Power editors") which has full content access, but no admin access (such as modifying roles). Then we reduce the powers of the existing Editor role so that it can delete (perhaps also edit) content that is "important". Then we should encourage users to not grant themselves more power than they absolutely need to have.

Prototype for modals:
https://projects.invisionapp.com/d/main#/projects/prototypes/18557240