Hi,
Here's the first draft of the complete document. It requires; copy edits,
redundancy blah blah. It should provide us with a starting point. A couple
more content checks and we might have something useable. I'm aware of some
problems and will fix them in the next version.
Emile, I'm sure you've got another project that you'd like to produce
documentation for. Let me know what it is, I'm down for the cause. My
tutorial project is at a complete stall which is attributable to not knowing
what I'm doing. As I learn more about Midgard and php I'll be able to
address the incomplete sections. A couple of the sections are
comprehendible and we could probably use them, I'll give that some
thought.
The nice thing about SiteGroups is I'm editing something that was written
by someone who knows what they're doing but doesn't have time to
document it. I know some people believe that documentation is best written
by newbies like myself. There's some merit to that thought but I feel it
needs to be qualified; programers should document their applications with
enough clarity for someone like myself to follow behind and edit the
material. Meanwhile, the programmer focuses on starting a new
application.
Ron Parker
Mi-Recordz
www.mi-recordz.com
[EMAIL PROTECTED]
SITEGROUPS
SiteGroups enables multiple virtual databases from Midgard's single mysql database.
Consequently when a user logs into a specific SiteGroup, they are only able to read
and write data that belongs to the SiteGroup. In addition to manageing access
privelages, SiteGroups fascilitates the use of one administration interface for many
users and it reduces the number of persistent database connections.
Consider Henry who owns vmuc.com and vmucentertainment.com; obviously he must have
administrative privelages for those Hosts, while it's equally imperative that he's
denied read and write privelages to anything that he doesn't own while useing the
Midgard administration tools. SiteGroups enables this type of environment.
CONFIGURATION
Building a SiteGroup aware Midgard installation requires that you reconfigure and
recompile all the midgard packages. This also applies when moveing from a SiteGroup
aware Midgard to a nonSiteGroup build. The inclusion of SiteGroups requires that you
specifiy "--with-sitegroups" during the configuration of libmidgard. The configure
programs for mod_midgard and midgard-php probe libmidgard to see if sitegroups are
enabled and respond accordingly.
The inclusion of SiteGroups during the configuration of libmidgard adds columns and
one table to the Midgard database. Existing records have their SiteGroup field set to
'0', so everything that exists when you apply the patch is owned by SG0. Users that
require full access to the Midgard database must have their "member" and "person"
records specified within SiteGroup 0 (SG0).
While SiteGroups is designed to be as transparent as possible, the transition to
makeing your administration tool SiteGroups aware requires the manual
instantiation of sitegroups. Insertion of SiteGroups is done from a mysql command line
by issueing:
INSERT INTO sitegroup (name) VALUES ('sitegroupname');[0]
To enable Henry's write permissions for vmuc.com we create the sitegroup "vmuc.com,"
add henry as a user and finally modify the vmuc.com sitegroup to include him within
its membership.[1]
USEAGE
When logging into the Midgard administration site, the user is prompted to specifiy a
username@sitegroup. Either a SiteGroup name or 0 must be specified. When Henry
specifies [EMAIL PROTECTED], mysql queries the host sitegroup field to determine which
records he will see in the administration interface. Only root users, members of SG0,
can remain in SG0 while logged in. Any user can log into the Administration site but
they are restricted to reading documents which are owned by the SiteGroup that they
signed in under and can only commit edits to the files they own.[4]
Creation of host records is limited to root users. To create a new host, log on as
admin@sitegroupname[3] and everything you build, including the host record, will
default to being part of that sitegroup.
Another SiteGroup feature is the administration groups--these groups can be thought of
as an umbrella under which many hosts are managed. Within this scenario the hosts
vmuc.com and vmucentertainment.com are both under the care of the vmuc.com SiteGroup.
Consequently, when Henry logs in as [EMAIL PROTECTED] he's able to read and edit the
records for both of these sites.
Members of administration groups have unrestricted create and modify access to all
resources within their sitegroup. Root users are automatically admin users for every
sitegroup. The admingroup for a sitegroup is specfied in the admingroup table. Both
the group and the person records must be in the sitegroup that they're admins for.
<!--End Edits-->
[1]David Guerizec is currently writing an admin-site interface for SiteGroups. It
should be available for the Midgard 1.4beta release.
[2]How to add another host to the vmuc.com sitegroup. In our example, Henri needs
write privelages for vmuc.com and vmucentertainment.com.
[3]Does the username "admin" have any significance or is it an example?
[4]This seemed to be implied but I'm not sure if I've interpreted it correctly. Does
it mean that a SiteGroup could display files which a user doesn't have write
privelages for?
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
