11
draj
Re: System Permissions
  • 2006/1/13 13:37

  • draj

  • Quite a regular

  • Posts: 271

  • Since: 2005/6/23


Quote:

bluenova wrote:
But what if you needed to give one group edit access to one module, but not to another?


In the CBB, I have the following:

Anonyme User
Can access
Can View
Can start new topics
Can Reply
Can Edit
Can Delete
Can Add Poll
Can Vote
Can Attach
Can Post without Approval

The same is for
registered Users
Administrator, etc...

Clicking on it and appliying it on the modules would do the trick!!!

12
davidl2
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/13 14:08

  • davidl2

  • XOOPS is my life!

  • Posts: 4843

  • Since: 2003/5/26


Kaotic - you're right... Please can you post the suggestions so Skalpa and other devs can see this... and link to this thread.

I'd also suggest posting this on Phppp's own site (www.xoopsforge.com) as this may also be relevent to him as well.

13
draj
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/13 15:00

  • draj

  • Quite a regular

  • Posts: 271

  • Since: 2005/6/23


Hi!

Thanks for the suggestion. I did know that, mate. I have placed a message :

http://sourceforge.net/tracker/index.php?func=detail&aid=1404819&group_id=41586&atid=430843

Hope that it gets implemented very soon as this will affect all the modules and bring an interesting change in Core. (So that we all could be a BIT happier)

14
draj
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/13 17:38

  • draj

  • Quite a regular

  • Posts: 271

  • Since: 2005/6/23


Hi!

I did not know who is behind the name Skalpa but I definately like his answer, very nice:
Quote:

Skalpa says: >>> sf.net thread
Don't worry m8, something like this WILL be done

You didn't need to make it a request, this is what the
"page-level permissions system" part of the 2.3.0
features
set is about.

Modules writers will be able to specify what kind of
operation their application allows (create cat, delete cat,
view cat, crate article, and so on...), and the permissions
panel will allow admins to set this up more easily than
actually.

Only thing: I'm not sure the "templates" idea is
really possible, as not all modules operations can be compared to each others, but to ease admins work as much as possible other ideas will get implemented:

- You'll be able to specify default settings, so a module
gets correctly setup right after installation.
- 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).


I just thought may be we continue to discuss further what is offered in his answer!

15
davidl2
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/13 17:41

  • davidl2

  • XOOPS is my life!

  • Posts: 4843

  • Since: 2003/5/26


Skalpa is one of the main forces behind the XOOPS 2.3 coding

You made your point to the right person there :)

16
draj
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/13 17:47

  • draj

  • Quite a regular

  • Posts: 271

  • Since: 2005/6/23


Hi!

Yeah, I can read and feel that behind those lovely words. But that was still a nice piece of advice from you guys! Thanks. I am glad that something better is already being planned for the future that gives me hopes to wait!!! Thanks...

17
davidl2
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/13 17:50

  • davidl2

  • XOOPS is my life!

  • Posts: 4843

  • Since: 2003/5/26


I'm glad as well - permissions and groups are 2 of XOOPS most powerful features, but they can be tricky to use sometimes... so improvements on this side are a big plus.

18
draj
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/16 7:15

  • draj

  • Quite a regular

  • Posts: 271

  • Since: 2005/6/23


Hi David!

You are right. I see that in Xoops, permissions are strongly implemented but the hierarchy is not inherited the best. It should work like a root, trunk, branches and leaves where:

- the root is a module,
- trunk is the mainpage or main category of that module,
- branch is the subpage or sub-category of that module
- and leaf is a single page.


This is my conception of XOOPS CORE PERMISSION CONFIGURATOR (CPC). Those should be stored in a separate table like I mentioned before. Thereafter they should be applied in the config table. The themes should be also sensitive to the Permission Tree Concept/Configurator.

I am not sure if Skalpa meant exactly that but if not, this would be reasonable to implement!!!

19
draj
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/16 7:42

  • draj

  • Quite a regular

  • Posts: 271

  • Since: 2005/6/23


Quote:
Skalpa wrote:
- You'll be able to specify default settings, so a module
gets correctly setup right after installation.


This also consequently means that during the module installation only the root permissions would be setup. One can click on what kind of root permission in regards to the groups needs to be installed.

The remaining trunk, branch and leaf permission would be done in the later stages.

Now the module installation is done in one step, where a lot of activity is configured. All at once.

What if this is done in two steps:
1) Function installation
2) Use / Permission installation.

With the Permission installation, one needs to specify which groups gets what permissions.

The same could then be reflected in the themes, as mentioned before.

20
draj
Re: Xoops CORE Configurator: System Permissions and functions
  • 2006/1/16 7:44

  • draj

  • Quite a regular

  • Posts: 271

  • Since: 2005/6/23


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.

Login

Who's Online

145 user(s) are online (86 user(s) are browsing Support Forums)


Members: 0


Guests: 145


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits