Quote:
Skalpa wrote:
- There will be 2 views in the permissions panel: 1 group
based (where you specify what members of a group are allowed
to do, as in the current 2.0.x page), and 1 location-based
(where you'll see a list of possible actions, and will be
able to select groups for each of them).
This will certainly NOT make the life more easy, I speculate. I respectfully defer in the conceptual approach with you in relation to your activity/location and group-property based concept of the new permissions structure of the XOOPS core!
The view in the permissions panel would not bring the conceptual clarity in thre minds of administrator. I beleive that it should a 3-Step Process, like I mentioned above the
Idea of a Tree which each User und Module developer could follow, that makes absolute clarity in the permission architecture in the admin:
1 - Module Level
2 - Category / Sub category level
3 - Page Level
Only then things would be a lot easier from the begining! In the user side, I beleive that the same should be taken over by smarty tags in the templates. Hence:
<% $module == "News" then appply module permission %>
<% $category == "Xoops" then appply category (or sub-category with inheritance) permission %>
<% $page == "developement" then appply page permission %>
Hence, I beleive the following would be very easy to visualise:
1)
Module mode: If I am in the module mode of the CPC, I shall see what module permissions each groups been assigned to. Here the permissions could only be basic permissions like Group, Access, Sub-Admin or Admin.
2)
Category mode: If I select from the drop-down menu the category mode in that module, if could see all the categories and sub-categories permission assigned to each group. Here, the permissions could be a bit more precise like, if Access permissions then view, edit, delete, move, etc...If Sub-Admin or Admin permission, then...
3)
Page mode: And if I select the Page mode of that category of a module, I see each page available to which I can assign permissions. If page permissions then it could also be based on quality of the permissions depending on the nature and value like, password protected page, secure page, modify, view, etc...
It is only through this 3-tier Architecture, XOOPS Core will bring clarity in the permissions.
Also, why should it be the business of a module developer to write permission names? It should be the business of the CORE to offer default permissions parameters that the module developers MUST use. They can be ofcourse be more at a later dated.
Only then the Core could offer a default template to configure permissions in the matrix of Groups.
