Hallo!

The entire permission system ist really taking a lot of time to configure. Moreover, it becomes more difficult to manage more sites that has a very complex user grouping.

I thought it would be better to have system wide permission instead of module related.

For instance, access or delete or edit are known functions. So it would be better that those calls are given by the system rather that each module developer developing its own system.

Consequences:

Hence if one installs a new module, then all the system permissions are installtly available of all the category we know about from super modules like, SmartSection, CBB, Article (Multi-Cat by Xoopsfourge), etc...

Currently it is there but implemented in a very complex way that each module has to have different application of permission category and not a system wide category.

Hence there would be a unified system wide permission system that could be applied to each and every module.

Only then there could be a better system wide permission manager, for instance a default template for all the modules . Hence, I can create new groups and make a new default template applying to all the system wide modules to apply system wide permissions.

Thanks

And that what we need, powerful and complex but less complicated!

A wonderful thing is, that a complex system does exists already but it is complicated.

Thanks for the vote.

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

Hi!

As you already know, especially as the forum moderator, the CBB module.

The CBB Module has default templates for permissions. This module is obviously designed for creating forums on an ongoing bases. Now imagine how difficult and time consuming would it be to install all those permissions for new forums and categories as well.

Hence it offers a permission template. VOW! I jumped from my chair. But then why does not XOOPS offer?

Hence if such a permission template is available offered by the XOOPS core, one could apply different access or edit permissions to different modules based on their Group membership Listings, exactly in the same manner CBB does.

In my suggestion, instead of the new Forum for which the permission template is to be applied, imagine Modules as a substitute.

What interesting I learned from CBB permissions structure is, that it creats a Matrix of Horizontal and vertical Layers for permissions, very very clearly defined. And this quality of clarity is definately missing in XOOPS core.

The Problem is due to the following:

Currently the matrix is >> Modules has different names of permission parameters.

module_name >>> read_permission

It should be a system parameter >>> System permission for >>>

Access or delete or edit system permission >>> module_name

This will reverse the Matrix from horizontal to vertical making the life much more easier to handle and less complicated.

Quote:

Therefore, one creates a new temporary default permission template and applies to different modules ::: AVAILABLE TO THOSE GROUPS:::

And that it the only way to make it less complicated having the complexity keeping the same. Eventually it results both into the same goal!!!

Hi!

To continue your discussion...

I was just now going through the comments. I found many mistakes of mine in different modules, they had different things, which I did ofcourse.

But that came to my mind that thats the same function and has the same nature to that of permissions.

If there is a system configurator with different default templates like

- permission template
- comments template
etc,

then one only needs to apply to diferent modules that appear into the listing of those appear under that colums for which the group permissions are given for free.

Hence I changed the name of the thread and re-named it to system congigurator, which is self-explainatory...

Thanks..

hmm, Sounds like an interesting idea to keep the individual module permission settings but to be able to set permissions on a global scale, and then to get and set any individual settings that need to be made in the relevant module.

A bit like the way you can in the smartmodules, where by each article/faq etc can have it's own permissions, but you can set the permissions for all articles through the category settings.

You got that mate! After writing this post, I kept on thinking on what I began to say, which I was myself confused for a while. Well, what I meant it following:

Global permissions: In one table, which is done now, there should be a template to work directly on this table. Alle the module permissions should be stored in there. But the permissions are in a lot more chaos than I thought! Here is my suggestion:

Basics:
Group 11 = Member
Module 17 = CBB Forum
Module 18 = SmartSection

Make a new table (System Core and site wide...)

and then give all the permissions ID! Take it to the

xoops_group_permission TABLE >>>
Now we have the field
>>>> gperm_name >>> which is useless


The above solution overrides any available module or core function available in the development of XOOPS including to that of Smartsection as the solution is changing the Shine of the XOOPS core.

Thanks

It certainly sounds like a good idea.

Hi!

Thanks david!

The modules from Smartfactory are realy smart and I love to use them.

However, I beleive that the new face of XOOPS MUST have the above solution. Only then we can begin with a new generation or atleast talk about it!!! The permission thing is very important and shall affect ALL the module developers.

What I see is the terrific development in the core that constantly makes the other areas (modules) of this lovely software redundant. Hence there is no real balance in the development except to that of some challanging developers like Smartfactory.

The CORE team is working so hard. If there are a few more developers joining the core, there would be no module developed (I am exagerating! The module developers wo'nt be able to run) and we, all users, would simply sit down only the XOOPS core and two other modules like extended profiles and PM! But that cannot be the public interest...

It would be worth to have the basics in the core frozen for a few years so that people and module developers could cope up with...Thanks

This is definitly a good ideia. Maybe it can be implemented as a hook, where each module "hooks" into the system permissions when setting it's own.
You should write a feature request over at sf.net so that scalpa, mith and the rest of the core team can look into this. Maybe one of them can take the time to properly implement this for 2.4, or, maybe you can come up with a coded solution? I'm sure the core team would gladly review code suggestions.