I am making a change to the permission system in GroupServer, as a way of
fixing the “Public to site members” sites¹. As a warning: the permissions
system in GroupServer reflects my opinions about permission systems. It is
intentionally opinionated.
The permissions system that GroupServer uses is based on the Access Control
Lists (ACL) provided by Zope. In *theory* an ACL provides fine-grained
control to access various functions. In *practice* they are a confusing
nightmare of options that are very easy to get wrong and hard to get right:
Zope provides a 7×122 matrix of permissions for a GroupServer group³.
GroupServer, instead, fudges a permission-system on top of Zope. (I call it
“privacy” to prevent confusion².) It presents the site-administrator with
three (rather than 854) options to control the privacy of a group: public,
private, and secret. These three privacy settings encapsulate the
underlying permissions.
• *Public* groups can be seen by anyone, including search engines, as can
the messages. In my experience it is very rare to have a group of this
type, but they tend to have many members.
• *Private* groups can be seen by anyone, but the messages are only visible
to group members. I wish this was the most common group privacy setting,
as it avoids a bunch of usability issues associated with Secret groups
(see below). I have made it the default permission because I *want* it
to be the most common.
• *Secret* is the most common type of group. Not that you'd know it because
unless you are a member of a secret group you cannot see it nor the
messages.
For the public to site members sites I am creating a fourth privacy
setting: *restricted*. A restricted group is visible to members of the
site, as are the messages and files posted to the group. In addition, site
members can join a group, without going through an administrator. The use
case is for an organisation where the barrier of entry is high (like a
corporation) but the site administrator wants a low barrier between the
different groups — to prevent silos forming.
The GroupServer interface will reflect the privacy settings on the Group
page, and the Topic page. However, at this stage the Privacy page for a
group will not provide an option to make a group restricted. Instead people
will have to hand-munge the permissions in the ZMI.
*Footnotes*
1. Bug 3978: Fix “public to site members” sites
<https://redmine.iopen.net/issues/3978>
2. As in gs.group.privacy
<https://source.iopen.net/groupserver/gs.group.privacy>
3. There are seven roles: anonymous, authenticated, site member, group
member, site administrator, group administrator, and manager. There are
122 permissions but GroupServer actually needs *more* *permissions*: I
hack around securing actions like posting, joining, and requesting
membership. This may be useful resource when I get up to fixing that
part of the system!
<http://developer.plone.org/reference_manuals/external/plone.app.dexterity/advanced/permissions.html>
fixing the “Public to site members” sites¹. As a warning: the permissions
system in GroupServer reflects my opinions about permission systems. It is
intentionally opinionated.
The permissions system that GroupServer uses is based on the Access Control
Lists (ACL) provided by Zope. In *theory* an ACL provides fine-grained
control to access various functions. In *practice* they are a confusing
nightmare of options that are very easy to get wrong and hard to get right:
Zope provides a 7×122 matrix of permissions for a GroupServer group³.
GroupServer, instead, fudges a permission-system on top of Zope. (I call it
“privacy” to prevent confusion².) It presents the site-administrator with
three (rather than 854) options to control the privacy of a group: public,
private, and secret. These three privacy settings encapsulate the
underlying permissions.
• *Public* groups can be seen by anyone, including search engines, as can
the messages. In my experience it is very rare to have a group of this
type, but they tend to have many members.
• *Private* groups can be seen by anyone, but the messages are only visible
to group members. I wish this was the most common group privacy setting,
as it avoids a bunch of usability issues associated with Secret groups
(see below). I have made it the default permission because I *want* it
to be the most common.
• *Secret* is the most common type of group. Not that you'd know it because
unless you are a member of a secret group you cannot see it nor the
messages.
For the public to site members sites I am creating a fourth privacy
setting: *restricted*. A restricted group is visible to members of the
site, as are the messages and files posted to the group. In addition, site
members can join a group, without going through an administrator. The use
case is for an organisation where the barrier of entry is high (like a
corporation) but the site administrator wants a low barrier between the
different groups — to prevent silos forming.
The GroupServer interface will reflect the privacy settings on the Group
page, and the Topic page. However, at this stage the Privacy page for a
group will not provide an option to make a group restricted. Instead people
will have to hand-munge the permissions in the ZMI.
*Footnotes*
1. Bug 3978: Fix “public to site members” sites
<https://redmine.iopen.net/issues/3978>
2. As in gs.group.privacy
<https://source.iopen.net/groupserver/gs.group.privacy>
3. There are seven roles: anonymous, authenticated, site member, group
member, site administrator, group administrator, and manager. There are
122 permissions but GroupServer actually needs *more* *permissions*: I
hack around securing actions like posting, joining, and requesting
membership. This may be useful resource when I get up to fixing that
part of the system!
<http://developer.plone.org/reference_manuals/external/plone.app.dexterity/advanced/permissions.html>