Features / Usability

Posted by joelg 18 Mar 2004 09:00 GMT-0000 posts: 104

To be more explicit - and in great hopes that this might get included in 1.9?

Sadly, I can't help with the code. I'm an old programmer but it's a long time since I hacked any code and I don't know any PHP, so I'ld call myself a "technically aware user" more than anything. However, I hope that this note might help someone else to overhaul the security system.

First off, I agree that the Tiki security is very good. In fact that's why I chose Tiki for this rather sensitive Intranet project - it is the only freeware CMS I've found with proper security, which would allow me to do what I wanted: set up separate Wiki structures and File Galleries for separate working groups, and apply security so that the groups could not access each other's pages or data.

However, now I've been working with Tiki a bit, I find that the way in which the security management screens are managed is extremely awkward and heavy to use. So here are a list of problems:

1) To set up a security structure, I want to create groups with specific permissions, then assign users to those groups. I also want to restrict access to Wiki pages and galleries to the members of certain groups. The way I have gone about this is as follows:

• create a group called "Editors" with permissions to update Wiki pages
• create a group called "Viewers" with permissions to read Wiki pages
• create a group called "SubjectA" for the "Subject A" working group
• create a group called "SubjectB" for the "Subject B" working group
• assign to each user (Editors OR Viewers) AND (SubjectA OR SubjectB)

The idea here is that the "Editors/Viewers" groups determine WHAT a user can do, while the SubjectA/SubjectB groups have no permissions attached, they are used to allocate access to pages.

2) Now the problems start.

• When I assign permissions to a group, the only way I can find to do this is to assign all the permissions in a particular level (a level is generally called a "role" in most security systems") to the group. I have a major problem with the "standard" levels (Editors, Registered, etc), in that they include permissions in throughout Tiki, including for a lot of functions which are not even enabled in my system. Result, I end up with "Editors" and "Viewers" groups that are bloated with unreadable permissions lists - and, incredibly, the permissions I don't want have to be removed one by one by clicking on "x", rather than by using checkboxes and hitting a submit button.
• Now, I understand Tiki having some standard levels - I don't complain about that. The way round my problem is to create some custom levels with limited sets of permissions and use these instead. However, there is no real way to do this. It is possible to create a level; it is even possible to change the permissions assigned to a level (though in a very roundabout way which means that a permission can only be attached to one level at a time), and there is absolutely no way to delete a level. In other words, the whole level management is a mess and badly needs some proper management functions. Personally, I believe in levels (roles) - they are not secondary but critical to good security management, and this should be sorted out in Tiki.
• But even supposing I get all my levels, groups, and permissions sorted out, when I come to the Wiki pages and File Galleries, I have to start all over again, because here I have to allocate the permissions one by one to the different groups which I want to access the page. Not only is this incredibly long and tedious, but IMHO individual permissions have no business showing up here at all, they should be kept where they belong, ie in the groups/permissions screen where they define what groups can do.

3) Finally, my complaint about Wiki structures is that although the permissions are inherited from the structure when you create a new page, you can't cause new permissions to be inherited when you make a change. And this is fearfully painful!!

This may seem very negative - it is not meant to be, on the contrary I hope these reflections may contribute to the improvement of a very good product which on the whole I am happy to use.

JoelG