An ever so often upcoming topic is how to extend Tiki's permission system form groups/category to roles/groups/category.
Here is an idea:
When I edit category permissions, I have the opportunity to copy the permission set of a group and simply paste it to another category, when I edit the category permissions of another category.
So copying a set of permissions work.
What I cannot do (currently), is to paste the very same set of permissions of the group which I copied from to another group.
The idea is, that I create a number of arbitrary groups as templates, which act as roles - let's call them "role templates".
Then I could create a category or use an arbitrary existing category to "store" those role templates, when I choose all the "role template" groups and apply the relevant permissions to those groups (to the "role templates") in that category.
So far so good - I can do that now.
But if I could here copy the set of permissions of each of them groups (for now one role template at a time) and then go to another browser tab where I open the permissions of another category and paste my copied set to another group there, then I would have given the group there the role permissions of the role template here.
Any arbitrary category A acts as container for the role permissions.
I have created following groups:
And apply appropriate permissions for them groups in category A
I have a category B
And I have created the following groups:
How it is:
If I copy the permissions of the group UserRTPL from category A to category B, then the group UserRTPL will habe the same permissions in category A and B and the group UserB will have no permissions any each one of both categories.
How it shall be:
Given Devs added an option, maybe a tick box or what so ever, to optionally inject the set of permissions to another group:
I copy the permissions of the group UserRTPL from category A and go to category B.
There I inject the copied set of permissions to group UserB.
1. Group UserRTPL (the role teplate) has still only permissions in category A, but none in category B
2. Groups UserB has no permissions in category A, but has in category B the exact same permissions as UserRTPL has in category A.
Thus I have given a group a set op role permissions based on a role template by simply copying the whole set from one category to another whilst defining the group that "get's the copy".
Depending on how deep to go into the code and how difficult changes might be, I can imagine that it could be possible to do some automatization to copy more than one at a time, for example to copy 5 sets of permissions of 5 role templates to 5 groups at a time.
Or it could maybe be possible to "teach" Tiki what a role template is and make it possible to apply the roles without the need to switch between categories.
Anyway having the opportunity to copy the set (as I can) and then inject to another group (as I cannot) would be a huge relieve in the context of permission management for any type of members areas or workspaces.
Show.tiki.org snapshot creation is in progress... Please monitor http:///snapshots/ for progress. Note that if you get a popup asking for a username/password, please just enter "show" and "show".
Password reset was successful
Password reset failed
Show.tiki.org instance destruction is in progress... Please wait...
The public/private keys configured to connect to show2.tikiwiki.org were not accepted. Please make sure you are using RSA keys. Thanks.
Unable to connect to show2.tikiwiki.org. Please let us know of the problem so that we can do something about it. Thanks.
Show.tiki.org is currently under maintenance. Sorry for the inconvenience.
Unable to get information from show2.tikiwiki.org. Please let us know of the problem so that we can do something about it. Thanks.
Show.tiki.org is in the progress of creating the new instance. Please continue waiting for a minute or two. If this continues on for more than 10 minutes, please let us know of the problem so that we can do something about it. Thanks.
To help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tikiwiki.org instance. To start, simply select a version and click on "Create show2.tikiwiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tikiwiki.org.
The URL for the show2.tikiwiki.org instance that demonstrates this bug is at: http://. Note that if you get a popup asking for a username/password, please just enter "show" and "show". This is different from the initial login and password for a new Tiki which is "admin" and "admin".
For the install log, see http:///info.txt
Note that if you see PHP errors or a Tiki claiming to be missing third party software, the instance creation is probably not finished. Please wait a couple minutes and reload.
Snapshots are database dumps of the configuration that developers can download for debugging. Once you have reproduced your bug on the show2.tikiwiki.org instance, create a snapshot that can then be downloaded by developers for further investigation.
Snapshots can be accessed at: http:///snapshots/. Note that if you get a popup asking for a username/password, please just enter "show" and "show".Create new snapshot
|No attachments for this item|