Issue: Giving each wiki article it's own editorial rights?

Bringing this to the front so that the default protection setting is added for 4.0.0 Alpha 1. caneditown is not needed so long as the default protection is author-only.

Just found this.

What is my suggestion and I think you already have that in mind is that there's always check if user is thread or article starter. That we can give some permissions based on fact if user started thread or article.

For example, I installed mod that enables indefinite editing of first post of any thread by thread author.

And with thread headers (similar to now existing forum headers, but they work in threads in the same way (or more advance)) for example, I'd like to enable that thread starter could work on them, but other users don't.

Default protection added to the Area Manager.

Unnecessary to disable caching for user-defined and user-level permissions. Instead, we can use a flag in the vw_user table like hasmask to alert us that this user requires an extra query. But the rest can be fetched from cache. Likewise, we can use the user's moderator membergroup to tell us that the user is a moderator, and query the permissions table for the extra moderator stuff. This way we aren't clogging up the cache with user-level permissions, but we're still caching permissions that apply to everyone.

Or, make some changes to the permissions fetcher...

Remove permissionkey field (node type id : node id : permission type : applies to id)
Replace with applykey field (applies to id : permission type)

Then we can search on applykey to get all permissions relevant to the current user, rather than all permissions relevant to the current page. Doing it this way is more intuitive and saves 5 queries on the all-feature test page.

Surely we can save 1 more query (except masked users and mods) by implementing the change in the previous post (caching group-level permissions), but the question is should we?

Has this been implemented?

Not yet, the form controls and handling for this have not yet been created. However, our permissions system already saves by page-ID rather than area-ID since Alpha 1 Badger in order to prepare for this feature.

Originally suggested for 3.0.11.

As a way of implementing something akin to XenForo's "Reply Bans" feature, but with slightly more control,
This is implemented in 4.1.0 Beta 2:

There is now a form where you can Allow/Block against specific users, for specific actions for permanent/temporary durations. If Block is used, the user's permissions are ignored, and they cannot perform the selected actions on that content. If Allow is used, the user's permissions are ignored, and they are allowed to perform the selected actions on that content anyway. If there are competing Allow and Block rules for the same user-action combination, the Block is used.

For pages:
- The form is part of the Protect tab. You may allow/block the Edit action.
This should allow pages which are collaboration protected, or have any other protection, to be editable by specified users.

For feeds:
- The form is part of the Protect tab. You may allow/block Adding entries to the feed.
This should allow feeds which have entry protection, to receive new entries from specified users.

For discussions:
- The form appears under the "Manage Reply Bans" link. You may allow/block Replies.
This should roughly emulate the reply-bans function.