Core Features

The current implementation adds a lock to all the pages automatically added through the add_xml() function (via the content.xml file.) By default, all those pages are marked as "cannot be deleted." And no one can change that from the interface (obviously, if you have direct access to the database...) As the implementer of a content.xml, you can change the default if some of your pages can safely be deleted and are expected to be deleted at some point.

Locking

We want to look into whether it would be necessary (i.e. that we don't already have a way to do so with permissions) to have some extension to allow locking of some content so a given user may be able to edit page A, B, and C, but not X, Y, and Z even though one should be able to.

There are two good reasons for this behavior:

A user may otherwise be able to edit very important pages such as the front page which only a very few people should be able of modifying.
Someone knows one is not always paying attention and wants to lock a certain number of pages to make sure that they don't easily get destroyed.
Home pages should not be deletable1
Another user is already editing that page contents (this is similar to a lock, not too sure whether it's part of this feature or part of the page feature...)
The system is currently updating that page (This one is already implemented.)

Locking the same as giving permissions, just the other way around (i.e. permissions assigned to a user results in the intersection of unions: (A union B) intersection (C union D). A lock would means one additional operation: either an intersection with another set which includes the few people who have permission to edit such and such page or an explicit exclusion of a set of people.)

See: Permissions feature [core]

See: Page feature [core]

See: Preemptive Editing feature