Another use case is if validation is being used as a 'has purchased' indicator. You want editing to not unvalidate, and you don't want to see the validation option.

This is slightly different to the original issue here. The original issue is about DENYing unvalidating, this is about PREVENTing unvalidating. In actualality it is the same thing.

We ideally need a new set of privileges.

I have attached a diff for calendars, which is hard-coded rather than privileges. Privileges could be built on top of this same model, which involves adding a new flag to the crud module's and also handling it in the form building logic.

It's actually a bit odd. We kind of have two converse privileges here.

On one hand, we want a privilege where we grant access to not have something auto-unvalidate when editing.

On the other hand, we want a privilege that lets people choose to unvalidate.

So maybe it is actually two separate things that need to tie together. Needs more careful though.

Also it would be good to be able to have it so you are allowed to only delete non-validated content.

This is all getting very complex. I don't want to bloat up the privilege system, so maybe this should work via pluggable code. Pass in state information consistently in the Composr API calls, and provide hooks that can perturb the configured permissions landscape based on that other state information.

Ok, so I've thought about this.

I think the best solution (although much more time consuming than 2.5 hours), is to change the current privilege model in a few ways.

Instead of these privileges:
add
edit_own
edit
delete_own
bypass_validation

...create a conceptual system of privilege levels:
add as unvalidated < add as validated
edit own to unvalidated < edit own keeping validated < edit all to unvalidated < edit all keeping validated
manually edit validation to off < manually edit validation to on (*1)
delete own if unvalidated < delete own < delete all if unvalidated < delete all

(*1 validation may automatically trigger to off, based on the other privileges, but behind the scenes, without a UI)

These could be encoded still using binary privileges, so long as it makes the assumption that if you have a higher level one, you also have the lower level ones. We can add an abstraction layer in the code to tackle the checking sequence.
The UI would show using lists rather than checkboxes though (when setting global privileges, and in permission tree editor).

The validation checkbox would only show on forms based on some careful logic. E.g. if your entry was validated and you were editing and had "manually edit validation to off", it would show. If your entry was not validated and you were editing and had "manually edit validation to off" it would not show, as there is no change you can make that would be able to take effect.

In all this there probably is a few days work.

There may be other privileges that could benefit from putting into levels. I seem to remember there being some that define acces to a 'low' limit and a 'high' limit, but in difference privileges.