1
XOOPS does not yet support multiple sites or sub-sites within a single installation.
Currently, there is an Admin group. Either you are an Admin, or not. Anyone who is an Admin can manage everything. Registered Users can interact with resources not restricted to Admins. Basically, XOOPS is an "all or nothing" framework. It works well for "standalone" implementations with one Admin team and one base of managed resources, like an internal Web server for an HR or Tech Support group.
The current framework is problematic when there is a need to go beyond "standalone" implementations. If multiple groups need access to resources from different XOOPS systems, members would need to have multiple username/password combinations. Members with a username/password would have full non-Admin access to all resources on whichever system. Each group would also have its own Admin members.
Businesses using XOOPS would greatly benefit if they had the abilities to:
* use "single sign in" across systems,
* selectively assign resource access rights,
* delegate partial administrative rights,
* administer multiple XOOPS systems from a single interface.
Module authors have no XOOPS API to do any of the above. Certainly, though, some of that fuctionality can be individually kludged.
For complex CMS usage or implementations of more than one XOOPS installation, XOOPS needs to be rewritten from the core level to allow management and directory cataloguing in an X.500 compliant manner. (Similar efforts use LDAP.) Furthermore, the XOOPS API needs to offer documented functions to query, administer, and interact with XOOPS installations, X.500 directories, and LDAP functions. Not trivial tasks. Fortunately, the conversion to PHP5 should present a wonderful opportunity to tackle this challenge.
Since XOOPS is the product of Open-Source, multi-author effort, it seems proper to have fora for XOOPS namespace, XOOPS single administration interface, and discrete XOOPS user rights for resource accesses. On the bright side, there is already an XOOPS LDAP effort.
Currently, there is an Admin group. Either you are an Admin, or not. Anyone who is an Admin can manage everything. Registered Users can interact with resources not restricted to Admins. Basically, XOOPS is an "all or nothing" framework. It works well for "standalone" implementations with one Admin team and one base of managed resources, like an internal Web server for an HR or Tech Support group.
The current framework is problematic when there is a need to go beyond "standalone" implementations. If multiple groups need access to resources from different XOOPS systems, members would need to have multiple username/password combinations. Members with a username/password would have full non-Admin access to all resources on whichever system. Each group would also have its own Admin members.
Businesses using XOOPS would greatly benefit if they had the abilities to:
* use "single sign in" across systems,
* selectively assign resource access rights,
* delegate partial administrative rights,
* administer multiple XOOPS systems from a single interface.
Module authors have no XOOPS API to do any of the above. Certainly, though, some of that fuctionality can be individually kludged.
For complex CMS usage or implementations of more than one XOOPS installation, XOOPS needs to be rewritten from the core level to allow management and directory cataloguing in an X.500 compliant manner. (Similar efforts use LDAP.) Furthermore, the XOOPS API needs to offer documented functions to query, administer, and interact with XOOPS installations, X.500 directories, and LDAP functions. Not trivial tasks. Fortunately, the conversion to PHP5 should present a wonderful opportunity to tackle this challenge.
Since XOOPS is the product of Open-Source, multi-author effort, it seems proper to have fora for XOOPS namespace, XOOPS single administration interface, and discrete XOOPS user rights for resource accesses. On the bright side, there is already an XOOPS LDAP effort.
