"Admin-level" page permissions

[niklaka]

cc: @apeisa @teppokoivula

Currently "edit access" covers these permissions:

• page-edit
  • page-create (not in database, ultimately a page-edit check for us)
  • page-add (not in database, ultimately a page-edit check for us)
• page-delete
• page-move
• page-sort
• page-clone & page-clone-tree
  • used only when ProcessClonePage is installed

(And "view access" covers only page-view.)

But there are other page permissions as well - how should these be handled? One straightforward solution would be just to add these to the above list:

• page-template
  • Changing template of a page.
• page-lock
  • Locking/unlocking a page.
• page-publish
  • Does not exists in stock install but kicks in once defined in global permission list.

My intuition says page-template and page-publish should be added to the list but page-lock could be left to be checked via roles. Then again, having anything more than plain page-edit should probably be configurable via module options (defaulting to the whole list).

Having said that, I'd be inclined to add all three to the list and implement a configuration option not to rule out any use case. Adding them all in at this stage also lets us pass this for now ;). Then later on an option and proper role iteration for those not in the list. (Can't just pass them through to template based access control as that would require defining things at least for home template and we don't want that.)

[teppokoivula]

"Then again, having anything more than plain page-edit should probably be configurable via module options (defaulting to the whole list)."

Agreed. List of all available (page-related) permissions (except page-edit) sounds like a preferable thing here, as it's quite likely that the requirements vary between sites. At least until that's implemented, I'd bundle all of these with edit access.

If we're taking this further and making "edit" configurable, this brings up another question: do more-or-less hard-coded "view" and "edit" make sense in the long run?

What I mean is that making even these configurable and allowing more of these "access roles" (in lack of better term) to be added is one option. I really prefer the simplicity of current approach, but a more configurable method would make it possible to define page-based permissions in a great detail.

Technically that would mean converting "edit" to a role and cooking up some method of making selected roles available for use of this module. In addition to that, it would apparently require a whole bunch of other changes under the hood (just had a quick conversation with @niklaka about this).

Doesn't sound like something we should consider for 1.0, I just wanted to bring it up somewhere :)