Chapter 9. Managing Users
So several sites can be managed independently thanks to Sitegroups. As for access to various parts of a site, Midgard's permission system is based on Group ownership, and controls only write access to the database records.
In addition to that, Pagelinks provide restricted access to a Page depending on Group membership.
As you can see in Figure 9-1, Groups are organized into a tree structure. Persons, that is individual users, may belong to any number of Groups thanks to the Member Table.
The realm field in the Sitegroup table is a string which contains the Sitegroup name, and is used instead of the name field in the authentication window opened by your browser. The name field is an identifier which cannot contain whitespace.
Read Access
When authentication is required, read access to any record within a Sitegroup is granted to all the users in that Sitegroup. More comprehensive read-level access control has to be implemented in PHP (which is easily achieved checking against mgd_is_member($group)()).
Write Access
Write access - which includes creation, modification and deletion - is granted to any user who is either a member of the owner Group the record belongs to, or a Member of a Group which owns a parent of that record.
In other words, users get write privileges for any sub-tree whose parent node owner is a Group they belong to.
Users, and Articles authors and lockers
Users have full read access for their Sitegroup and Sitegroup 0. Their write privileges depend on the Group(s) they belong to.
In addition to this, being the author of an article grants write access to it.
An article may also be locked. Anyone with write permission to an Article record may lock it, but once it is locked, only the locker and the Sitegroup administrator can unlock it. This is illustrated in Example 9-1.
Pagelinks
In Figure 9-2, two Hosts with the same name and different port fields are associated to the same root Page. The Host that uses SSL has its info field set to "auth", which means it requires authentication.
Four Pagelinks with the same name have the same parent Page (their up field is set to the id of the Host's root Page). Their target and grp fields, however, are different. Let's assume that the admin Page leads to the site's administration interface, and requires authentication.
Authenticated users belonging to Group 101, 10 and 102 will be directed to the topic, administrator and style Page respectively. Authenticated users who don't belong to any of these three Groups, and non authenticated users will be directed to Page 404.
A user who belongs to Groups 101 and 10 would be redirected to the topic Page: When there is an ambiguity, the Pagelink with the highest grp value is used. This wouldn't make any sense in our example, as the topic Page is a child of the administrator Page.
This illustrates the possible use of additional root Pages for one Host. Something similar can be achieved without Pagelinks, with an authenticated admin Page, but this type of solution is more flexible, and doesn't grant default read privileges to any registered user.
Preferences
Preferences enable you to personnalize the content of a site. They are name and value pairs attached to a person, and they may be grouped by domain. This feature is deprecated, as you can achieve the same thing thanks to the Parameter table and functions.