Contentdokter

houdt uw content gezond...

Skip navigation.

CMS Blog

Teamsite groups

One of the most useful features for a Teamsite administrator could very well be the flexible Teamsite groups.

These teamsite groups, which are equivalent to groups at the os-level, have two major advantages over these os-groups:

  • they are controlled by the teamsite administrator
  • they have to option to add a group to a group, empowering a hierarchical set up


The first is important because the os-groups are normally managed by a far away department that is usually slow to react. Adding or removing a user from a group could easily take days, leaving the end-user without proper access to Teamsite.

The second is maybe even more important because this, once set up right, enables the teamsite admin to easily add new users the proper rights by adding the user to 1 group only. Example: a basic group division would be 1 group of global adminstrators, 1 group of developers per 'teamsite-project' and a group of content-editors per 'teamsite-project'. Normally the developers have the same rights as the editors and some more and the admin's have all rights of the developers but IN EVERY PROJECT. This can be done by creating these groups:

  • a group for the editors which contains all editors and the developers-group (per project or branch)
  • a group for the developers which contains all developers and the admin-group (per project or branch)
  • a group for the admins


Does using these ts-groups also have disadvantages? Sure:

  • The iwchgrp clt does not work recursive where as chmod -R does
  • In the os-level privileges all you see is the iwglobal group


Posted am 02.12.2007 Kategorie:Teamsite Kommentar hinzufügen

OpenDeploy 6.1.1: no news except a license key

OpenDeploy 6.1.1 has been out for quite a while. I have not had a look at it for a while but I don't think there was any reason to look at this version before: it does not contain much news.

The new features that are included are not that shocking (some new adapters and an option to only deploy files at the root-level, I'm not sure yet what good that is for).

But it comes with 1 major drawback and one that is well hidden in the release notes: you must obtain (and install) a license key for each install (both base server and receiver). This fact should be WRITTEN IN BOLD in the release notes but no, Interwoven has chosen not to mention this at all. How stupid can you be? The good thing is that license keys for receivers can be installed remote via.... opendeploy!!!. That is indeed quite nice.

And obtaining an license key is the same old hassle it has been since TS65 Sp2: via a website that is running on (or should I say hidden behind) port 8080. This port is, in most sensible enterprises, blocked for out going traffic. And thus you either have to use your private home internet connection, how professional, or send a request to support via email. Either way, it will cost you extra downtime, something that you can do without on any production server. You would think Interwoven would be wiser and run this website on a decent port, well let's say port 80.

Little tip for if you want to install Ts65Sp2 on a production server AND minimize downtime: install the service pack on another server, copy the license-detail executable to your production server and run it. It will return the needed details to generate a key BEFORE you run the Sp2-installer.

Posted am 22.11.2007 Kategorie:OpenDeploy Kommentar hinzufügen

Teamsite 6.7.1: new workflow modeler

Teamsite 6.7.1 comes with some very nice features again.

First of all Linux (Red Hat 4) is now supported as a platform to run Teamsite on.

Further Teamsite on Unix will now run as a non-root user. I'm not yet convinced by this feature. You still need root to install TS and to do the most admin-tasks. So in most enterprises you will still need to be very nice to the system-admin with the root-password.

But the best thing in this release is the workflow modeler. A graphic GUI to design and develop your workflows. All Java-based. If done right this could be a very good thing. Java-developers are easier found then perl-coders and workflow are just easier to design in a graphical mode. If only to keep the managers that always enjoy a good image happy.

The old wft-style workflows can NOT be converted, will be phased out in the long run but for now are still supported.

Posted am 20.09.2007 Kategorie:Teamsite Kommentar hinzufügen
Your language: Nederlands In english Auf deutsch En français