Delete page permission #52
Conversation
|
Generally I think this looks great, and would support adding the new permission types. I do have a few small concerns over the UI for adding/removing permissions: with the new list you propose, it's not easy to compare permissions, and particularly to see when someone is missing a permission, you have to scan the list and mentally subtract it from the list of all permissions, unlike our current design. I wonder whether a list with ticks/crosses (even if uneditable) would be clearer? |
|
@jacobtoppm My feeling is that showing the full set of available permissions against each row (as opposed to just the currently selected ones) is too much information to be manageable, whichever way it's presented. Happy to be persuaded otherwise though :-) Maybe we could get away with just the short permission names ('Add', 'Edit', 'Publish') being displayed in the listing, and switch to the full descriptions when editing them? Perhaps @wagtail/ux-design can chime in... |
|
As an addendum, the same feature has been requested for Collection-based models (Image and Document). However, as there are some extra technical details to resolve there (updating the |
|
Are there plans for solving the problems that caused this RFC: not being able to mark something as "archived" and the fact that delete is destructive? |
Traditionally, Wagtail's permission model has treated page deletion as equivalent to editing, on the basis that deletion is no more destructive than editing out the content from a page, and withholding delete permission will tend to result in editors using unsatisfactory workarounds, e.g. changing titles to "DELETE ME" or "DO NOT USE". However, deletion does differ in that revision history is not preserved, which may be particularly significant in settings with strict audit logging requirements. We therefore propose splitting deletion into a separate permission type.