Hallo!
I was checking other systems and framework in this
regards. Hence I came to the following idea:
If the group permissions are based on the unix
permission system like 777 (Global full access), 700
only user has full access, it would be the best and
ideal solution. The complexicity of the permission
system of unix is in the heads of all the xoops users
and developers.
Now if this system of permission concept is
integigrated into the Xoops permission concept, it
gives an extra-ordinary value to Xoops in regards to
its complexity. Those groups numbers would be read in
the early phase of the call through index.php anywhere.
Therefore, it could be taken forward into various
modules. For e.g.:
If the Admin or a user uploads a file, it can be
mentioned what level should Xoops would understand the
permission as, when the file remains on the server.
This therefore would be seperate to the group permissions.
Now, Xoops offers groups (permissions)
.........but......not......permissions.....itself! Then
those permissions could be also inheriten by objects
that follows through the data_calls.
Whens the (unix) permissions (through groups) are
originally offered and saved, it would make the core
very different to all other systems as this quality NO
OTHER SYSTEM HAS ACHIEVED!
Logged In: YES
user_id=1329834
Hallo Skalpa!
I suggested earlier to have a module <> permission <> groups
table linking. This message is here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1404819&group_id=41586&atid=430843
Thinking on it, I thought that it would be better to have a
strong permission system which is NOT module related but
really PERMISSION QUALITY related. Here the best possibility
is ofcourse Unix system as described above.
OK, I checked in the db and found out which and where:
IN the table xoops_group_permission
......gperm_name.......
has been a place to play by all the module developers.
This funny play has been going on since there has been no
disciplinary and controlling sub_routines available in Xoops
Core. If there was anathor table available to define the
quality with the name
........xoops_permission_type...
where the quality of Unix permissions would be stored, then
the module developers would simply have to insert those
numbers like 700 of 777 unix permissions. With this system
the core and all modules would understand the system of
permissions.
Therefore, I suggest the following:
1. --------------------------------
Make a new table xoops_permissions_link
perm_id perm_name perm_type
1.........rwxr-xr-x...0755
2.........rwxrwxr-x...0775
3.........rwxr--r--...0744
4.........rw-r--r--...0644
Apply the quality of permissions to modules.
There cannot be a group permissions assigned to a group in
this theory.
The modules would have the user, group and system
permissions anyway. Hence,
User = Site Account or vHost or $SiteGroup ist the
owner/User of a module
Group = Group within a site
Other = Everyone, Server and system functions
Table xoops_group_permission
May be this may be interesting to discuss! Shall I make a
sketch with tables of this idea? Does this idea make sense?
Logged In: YES
user_id=1329834
Hallo!
Very interesting. Was just surfing and found out that this
what I suggested is really nothing new but has already been
implemented. In this computer world have no surprises with
similar situations! ;-)
Here you can see:
http://www.awf-cms.org/
Ofcourse, I should have mentioned that in Xoops Core
permissions, there cannot be execute permissions. Hence it
could only be access, write and delete.