After a great deal of thought, pacing, and brainstorming though, I was able to come up with an enhanced permission scheme that had all 3 of the key elements:
- quick to set
- easy to understand
This permission scheme works by allowing many of the ocPortal specific permissions to be optionally overridden by modules and content-categories, such that entries in those categories/modules take on the overridden permissions.
This is really useful for some situations. For example, a website that generally allows members to submit downloads might want to protect one of their categories because that category is intended solely for distribution of official files made by the staff of the website. This would now be possibly by overriding the 'submit midrange content' specific permission for that special category.
A second permission issue, that has troubled me but no one has complained about yet, is that in order to change permissions for a usergroup in 20 categories you need to locate and proceed through 20 edit screens. It's not as if this is a regular occurance, but this disparacy is certainly awkward, and also makes it difficult to see the permission landscape. For this reason, we have created the new 'Permission Tree Editor': an editor which allows viewing and editing of most ocPortal permissions in a single window. (It's actually very similar to our new Site Tree Editor announced last week)
One particularly useful feature in the Permission Tree Editor is the ability to easily select large portions of the tree and then applying common permissions to those. This is most useful when setting view access. For example, if it was decided that the 'Naughty' usergroup should be able to access download categories when they were not able to before, one could merely select all download categories, tick for there to be view access, and then edit the whole selection at once.
I can tell you that it sure wasn't easy to come up with the new permission scheme, although now that it is done I do feel it is quite intuitive and perhaps obvious. In reality though, it required hours of mind exercises about segmenting a roughly 20-dimensional space into filled and non-filled regions, where the filling represented the having of permissions, and the axes representing the different factors that might influence permissions (such as usergroup of the member involved, whether the member involved was the content submitter, the content's module, the content's category, and the type of permission required). The trick was to find the shortest way to define the average kinds of shapes, whilst not limiting the shapes that might want to reasonably be created in rarer situations. That's where the idea of 'overriding' comes from - thankfully it turns out to be an intuitive concept, but I actually came up with it from the abstract idea of making complex shapes in 20-dimensional space by starting with big 20-dimensional boxes and then painting over increasingly small boxes to make the detail.
I hope some readers will understand what I'm getting at, because I think it's pretty interesting, but it might require a fair amount of insanity to follow .
Tomorrow I'll be explaining how we hope to find a new balance between community and corporate. I know this is something our users on both side of things care about a great deal.