Planet Ergo

The Kolab web administration panel is being re-factored, or should I say, developed from the ground up.

We're splitting the user interface and the backend logic into a frontend "client" and a backend API, in order to allow for easier integration within other management and corporate products. The frontend client, the user interface I'm about to show off, therefore calls upon the API to get to certain settings, logic and other fancy stuff. Let's see what it can do already;

See here the client login screen. Once you press submit, it actually calls the API to create you a session, and tokens are being bounced back and forth. The way this works (or is supposed to work) exactly is documented in our Architecture and Design guide. Currently, we only allow login with either the LDAP Distinguished Name of a user, or the primary mail attribute value - this is to be improved still.

After (successful) login, you'll be taken to an overview screen - I'm thinking this is to, in the future, display tasks pending (for sysadmins), and/or overall status of one's Kolab deployment.

You can see there's some icon work to be done, still, and that we're not yet "fully featured". We have an idea of how it's supposed to work, of course, but we're nowhere done implementing all of it. The key functionality is to first implement administration for "users" and for "groups".

While this development deployment of the new Kolab Web Administration Panel runs against https://webmail.klab.cc, with currently over a hundred users or so(!), and with our larger deployments running with hundreds of thousands of users, we have considered user administration to become 'search based' as opposed to 'list and browse based'.

We've still provided a listing of (20) users, which is currently not configurable in size, with browsing capabilities. This, including a variety of other changes Kolab Systems has developed, should allow very large user databases in LDAP to still function properly with this interface. Please note that I've logged in here with my personal credentials - not the System Administrator credentials, which is why I'm only seeing a sub-set of users that are actually in the system.

Now on to one of the nicest features we've developed; Automatic generation of certain form fields when adding a user (of a certain type). We currently ship with one default user type only; the "Kolab User". We're working on allowing administrators to define their own user and group types, so that adding a user or group offers you a quick way to identify required attribute values, and allows other attribute values to be generated using the information you supply. Have a look;

We're adding a user here. I give the user a given name attribute value of "John". Nothing is happening yet, but here it comes;
As soon as I leave the textbox in which I am to supply the given name attribute value, the frontend client calls the API to generate "other attribute values" given this new information. You can here see that the display name is being filled out automatically.
Now, having supplied the surname, please find the display name is completely filled out. The mechanism applied here contributes to consistency for multiple adminstrators working to add users to the same Kolab Groupware deployment. But that's not all of it!
In the System tab, other attribute values are filled out automatically as well - again using API calls. In the background, the API is using the same settings as are provided to the new Kolab daemon that I've developed, so that the daemon's "recipient_policy" plugin - if enabled, of course - does not have to change the same attribute values afterwards.

These "auto" form fields, calling the API in the background, are going to become fully configurable. That is to say, 1) which attribute values are to be generated automatically, 2) using what form data already provided, 3) rules to authorize someone to override automatically generated values, and 4) per user/group type.

I've mentioned "user and group types" a couple of times before, so let me illustrate what that's supposed to be able to provide you with.

Sometimes, you just want to add "a Kolab User" - this entry is supposed to have a mail attribute representing a valid email recipient address (and email envelope sender address), amongst other things. Suppose however you want the user to just be "a POSIX user" - but without Kolab Groupware. You would add a user type called "POSIX user", and set the mandatory, recommended, automatic and other form fields (and values), and from that point on forward, whenever you add a user, you get to choose what type of user that should be.

Of course you can make this "whatever you like" - if all "Kolab Users" are also supposed to have POSIX attributes, and Samba attributes, and the like, you can just add these form fields to the existing "Kolab User" type.