Making a page editable but not deletable

[evan]

Another question --

Is there a way to make a page editable but not deletable, on a page-by-page basis?

I would like my client to be able to add children, edit the parent, but not delete the parent.

Thanks!

[ryan]

Usually you'd handle this with two roles. One role that has page-edit and page-delete permissions to be assigned to the template used by the child pages. And another role that has page-edit and page-add permissions, to be assigned to the parent's template. By "assigned" I mean, check the box for it to be "editable" to each of those roles in the template's access tab. Then you'd give the user both of those roles. But I realized after trying it myself that it wasn't quite working as intended. I committed an update to the dev branch so that it should work now.

Btw, your client won't be able to actually delete anything either way. The definition of "delete" to non-superuser roles is just to move to the trash. So if you don't want to move to the PW 2.2 dev branch just yet, at least take comfort that if your client happens to delete something you don't want them to, you can always go back and undelete it.

[apeisa]

Btw, your client won't be able to actually delete anything either way. The definition of "delete" to non-superuser roles is just to move to the trash. So if you don't want to move to the PW 2.2 dev branch just yet, at least take comfort that if your client happens to delete something you don't want them to, you can always go back and undelete it.

Actually it would be great to allow clients to see and recover pages on trash, but not able to delete there. It will save bunch of support work, because accidental page delete won't require support call. Also there are cases when they do want to completely delete page, so when client deletes page from trash, then it could be set as hidden (so that superuses could still see and recover those).

[ryan]

Trash is tricky because if a page inherits it's access, then that association is lost once moved to the trash. The trash is undefined in terms of access control–a no-mans land. Some pages in there may be using templates with access settings and some not. It becomes a can of worms if we let non superusers in there. We'll find a way around it down the road, but in the short term I think it's safest to lock that part down to superusers.

Others experience may be different, but I've only ever had a client delete something they weren't supposed to just once, and that's over several years. But that may also be because a lot of the sites I deal with rarely need stuff to be deleted, so it doesn't come up often.

[apeisa]

Others experience may be different, but I've only ever had a client delete something they weren't supposed to just once, and that's over several years. But that may also be because a lot of the sites I deal with rarely need stuff to be deleted, so it doesn't come up often.

That is very usual for us (even that our in-house cms has nice "recover from trash" functionality). Of course it depends on cms used, what type of sites and clients. Our sites usually have 5-20 editors with very variable knowledge and it-skills, so accidents do happen.

[ryan]

Time-limited recover from trash is something that we could do for those users. That's because that user would be listed in the page as the modifiedUser. That's enough for us to assume that they at least had access to it, before it was deleted. We just need a way to determine where the page originally came from in order to restore it. But that could be as simple as encoding the original parent ID in the title field or something. So even if we don't let them go dumpster diving, at least we could let them sift through their own trash in some form or another.

[apeisa]

This came up once again when I was teaching PW for our clients. It was 5 min for the first "Oops, I deleted something and I want it back".

What I started thinking that how about having this with additional page status, something like "removed", which hides it all together from admin site tree and makes it unaccessible from selectors. But it still keeps it original position and it isn't moved anywhere. It could also have some "safe time", like 30 days before it is removed finally (or maybe moved to the current trash).

Then we would have "personalized trash", which would show all the removed pages that user did have editing access and they could edit and recover those pages.

Just an idea - I do find current trash somehow limited.