I think it is essential that Tikiwiki have some method of
restricting access to various pages by various user
classes or it will never gain wide acceptance. For
example, I have created a website
(http://www.newwarriors.org) that is open to all
registered users, but the organizations financial pages
are to be limited to initiated men only. The Human
Resources Department of a company wants to publish
job openings company wide but wishes to restrict salary
information to upper level management.
The current Group system can protect some pages in a
very cumbersome way (each operation must be set), but
other objects are not protected at all. Further,
permissions are not carried through to child or linked
I see two ways to create the necessary security. The
first way is to have every page, forum, gallery, and
other object have a permissions section similar to that
found in the admin module section where Group viewing
privileges are assigned (although this is not working
properly in 126.96.36.199). Only those groups assigned to the
page/object can even view it, and of course, the other
group permissions apply as well. Multiple groups can be
assigned to a page/object. This implies that any object
derived from or linked to from the Group protected page
must inherit its Group properties from its parent.
The upside to this approach is that groups already exist
within the Tiki framework so maybe the required mods
would not be gigantically hairy.
The downside to these mods is that it makes Groups do
more than one function, which is currently to define
what a user can DO. Second, it means that a lot of
groups and subgroups need to be setup in order to
accommodate this method.
Consider a small company, the Wiki Widget Company
(wwc on Nasdaq). The company has three levels of
employees: Managers, Grunts, and Peons. Managers
can look at all stuff, Grunts can look at their stuff and
Peon stuff, and Peons are well peed on they can only
look at their stuff. So, three Groups could take care of
the page view problem.
However, within each group, there are still admins,
editors, and viewers. So, now we need to have 9
Groups set up in order to restrict view access yet
provide for group permission functionality.
There is yet another problem. The Wiki company has
three departments: Manufacturing, Sales, and
Accounting. Each wishes to have its own protected
areas; only Sales Managers can look at Sales deep dark
secrets, etc. To do this only with Groups means that
there must now be 27 defined Groups in order to provide
complete flexibility with respect to page/object viewing.
It is clear that this is an exponential problem. Four
departments with four levels of employees and four
levels of permissions yield 64 groups.
The second way to approach this is to create a new
security variable, the Section. Each page/object has
an additional field on it; the Section(s) assigned to it,
and all child pages/objects inherit the section. Each
user is now assigned one or more Sections in addition to
being assigned to Groups. Now, page access is
controlled by the section and edit/update permissions
are controlled by the Group.
This approach gets us back down a reasonable number
of entries for the Wiki Company. First, there are only
three Groups: admins, editors, and viewers. However,
there must still be nine Sections created: For each
department, there must be Manager, Grunt and Peon
Sections. So, 12 entries need to be managed. For the
example of four departments, four levels of employees,
and four group permissions, the number becomes 20
instead of 64.
This approach creates a 2D matrix of viewing and editing
permissions. A truly ideal security system would
implement a 3D matrix security permissions approach. In
addition to the Groups and Sections described above,
a Level is also added. Each user is assigned to one or
more Levels in addition to one or more Sections and one
or more Groups. Each page/object and its children now
have both Section access control and Level access
Now, three Groups are set up: admin, editors, viewers.
Three Sections are set up: Manufacturing, Sales,
Accounting. Three Levels are set up: Managers,
Grunts, and Peons.
Upsides: Groups retain their original function; in fact
the view permissions are no longer necessary. Users
are assigned with maximum flexibility and admins have a
minimum number of entries to maintain. This also
eliminates the exponential growth problem. Downsides:
Lots of coding.
I close by commenting on a suggestion made by Marc
LaPorte that Categories could be used as Sections as I
have described them. While this sort of works, it limits
the ability to index pages/objects as Categories are
intended, and it makes view management difficult.
Consider our company once again. They want their
website information organized into Employee
Information, Product Information, and Internal
Operations. Categories are great for creating this
organization. For example, all the open jobs from Sales,
Manufacturing, and Accounting are published
independently by each department with the Employee
However, if Categories control views, then either these
particular categories could not be used unless I went
through the clunky process of having subcategories for
each department and management level. To provide the
same view access as previously described, Id potentially
need 9 subcategories in each category.
Im hoping you folks can have this ready for V 1.8.
Seriously, if one looks at commercial packages, or some
of the sites set up with shareware MySource from
squiz.net, youll see that there are restricted sections,
and it is based on a department/section concept.
Thanks for permitting me to share my views.
Log in to post a comment.