Loading...
 
Features / Usability

Features / Usability


Permissions: yeoww, very painful!!

posts: 104 France

I have just started setting up an intranet for several collaborative projects using Tiki, my favorite choice because of its flexibility, provision of about every feature I can think of to provide, wide choice of languages, and above all SECURITY.

This intranet site fields collaborative tools (wiki pages, forums, file galeries) for several groups of users. Because the work they all do is fairly sensitive, I have the requirement to separate them carefully. So I create groups, and only allow access to the resources to each group as appropriate.

But boy, is this PAINFUL!!? evil

For example, I want to set up some Wiki pages for my users. I set up a structure (Wiki pages must always be created under a structure). I discover that permissions are inherited from the structure when a new page is created. Gooood! lol

Then I discover that if I change the permissions in the structure, the permissions are not inherited in existing pages and I have to do it manually. Baaaaad! cry

And as for adding the permissions in, it takes forever because I have to manually assign about a dozen permissions, one after the other, to each page. Veeery baaaaaad!! mad

Then if I have to change anything it starts all over again..... Curse, swear, jump up and down and scream.... evil

Dear Tiki developers, a way out of this mess exists!! razz It is called the level. If only the level was properly managed (eg you could modify and delete them as well as creating them), then you could attach levels to pages (or anything else - same problem with file galleries for example), in one click. And if you made sure that structure permissions could be inherited to all existing child pages when they are modified, all my problems would go away. Please?? wink

JoelG

posts: 2881 United Kingdom

Hi,

Tiki perms may be painful but they are damn good once you understand them :-)

The Levels shouldnt be made available at objects. What would be much better is to correct the original problem of changing permissions for a structure.

btw. You can create wiki pages in a number of ways creating a WikiWord for example on an existing page and clicking its ? when saved. Or by adding the quick edit a wikipage module.
or even just tiki-edit_page.php?page=PageNameHere

Hope it helps, can you assist us in the structure permssion code?

Damian

posts: 104 France

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


posts: 104 France

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


Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting