[Typo3-dev] SetGroupID for pages

Martin Poelstra martin at beryllium.net
Tue Feb 3 09:59:47 CET 2004


Hi Jörg,

> well, I can't imagine how your structure is set up. But I do know how
> universities are divided into faculties and courses of studies.

Same here.

> We're
> working also for a german university and there are also a lot of backend
> users and even more pages. But at each faculty there's a bunch of
> editors, administrators, site builders and so on. So for each branch of
> people exists a corresponding backend usergroup which are split up into
> the course of study. Based on this courses the site tree is build. If
> you set the mentioned conditions according to the groupid's, everything
> should be fine.

True. It would be fine, however, we want every secretary (SecUser) to update
his/her own part of the site, which will be only a few pages (mostly the
leafs of the tree). Now, we want his/her boss, FirstBoss, to be able to
update the somewhat more general pages just above the pages of SecUser, but
also the pages of SecUser. We will also have a SecondBoss, ThirdBoss, etc.
These will all be in groups, which have the lower levels as subgroups.
Now, using conditions is actually possible, but it will be a hell of a job
to maintain if you have hundreds of backend groups. If you change the Group
of a page, you'll also have to update the condition manually. Whereas if
it's just a flag or bit on the page, you don't have to do anything.

> You can use those conditions to set it for each branch of the site.
> Another possibility is to define for each entry branch a +ext setting
> the groupid. This one works also for all pages beneath.

Templates are even worse, because we'll have to create an +ext-template for
almost every page then, except for the leafs of the tree probably. This will
create so many cached versions of templates that it's hardly practical to
use cached versions anymore...
It is more logical to have it the unix-way and have all permission-things
together where they belong: in the permissions-fields of a page.

> Got me?

Completely :)
But what I want to have is a structure with (almost) a backend-user+group
per page. Now, this might sound ridiculous, but I don't think it is,
actually. The database won't have any problems with it at all, the only
thing I'll have to worry about is creating another backend-tool for
maintaining this huge amount of backend-groups and users, plus another tool
(or maybe just a slightly modified version of the current) to view and
control permissions on pages.
We currently have two trees: a page-tree and a file-tree. I would like to
add another tree to it: a group-tree, with the users as it's
contentelements/files.
I then want to be able to set a flag on some user (or maybe group), which
will enable him/her to create subgroups and subusers and give them rights to
change pages below his own page(s). I know I can do that with Actions. But
that's not what I want. I'd have to create actions for every 'subadmin', but
even then, they're not flexible enough.
Oh btw, I don't want to have many 'real' admins! I want to have, say 4
admins that are able to maintain the tables, templates, extensions, etc. The
webmasters of the faculties, services, courses, etc. have to be 'normal'
users, but with some extra power to create subgroups and users.

I think the group-tree will be beneficial for other Typo3-sites as well, and
especially if Kasper wants to help with supplying the proper hooks ("API's")
in the Typo3Core.

I guess I can be sure that the SetGID-thing isn't currently provided by
Typo, and that no-one else created it yet. I'll start thinking about
implementing it.
Anyone having suggestions for something like this? Wanted features?

Thnx,
Martin






More information about the TYPO3-dev mailing list