[Kolab-devel] Enabling multiple sieve editors on Kolab installation

[Georg C. F. Greve]

Hi all,

While it may not be totally obvious there are scenarios where multiple sieve 
editors should be used with one Kolab installation, e.g. when Kolab works as 
an integrated part of an existing infrastructure, or in an integrated product, 
such as UCS, which is in fact a real case.

These systems/infrastructures often have management interfaces for some things 
that require sieve, starting from spam/ham handling, over archival, or just 
plain out of office notices. At the same time, users still would like to be able 
to filter mail into folders.

We have had the request before that a customer would like users to set their 
vacation status through the appropriate management system, which should also 
set the email response, but should still be able to set per-folder filters.

Obviously, this means the editors need to ensure that they do not screw up 
each other's edits. 

The way to do this - I think - would be to use the "include" statement in 
sieve and make sure editors do not touch each other's file. 

So in other words, I'm thinking of having a "MASTER.sieve" which essentially 
looks something like like this:

	require ["include"];
	include :global "global-spam.sieve";
	include :personal "management-system.sieve";
	include :personal "my-own-filter.sieve";
	include :personal "some-other-management-system.sieve";

and is always activated.

The management system write the management-system.sieve, the user writes their 
personal sieve. Never the two shall touch each other. 

In more abstract terms, I've been thinking that we should have configurable 
lists for the Kolab Sieve Editors:

	global: an ordered list of global sieve script names
	preuser: an ordered list of personal sieve script names
	postuser: an ordered list of personal sieve script names

and a "magic" name for the including script, e.g. "MASTER.sieve".

The entries on the lists plus the "magic" name should normally be suppressed 
for the user, so remain invisible and not be opened for editing. The rest can 
work as usual, with the user editing the various scripts normally.

"Activating" one of these scripts means that it is placed in the include 
chain, the actually active (in sieve terms) script will always be the magic 
script that has all the includes. This script gets re-written and re-activated 
on every edit / change of activation.

We could of course also "activate" multiple scripts this way.

This would make editing sieve a lot more comfortable, but might also be 
confusing for the user, I guess, and break the expectation as to how sieve 
behaves.

Another question would be where to store the configuration values, in case 
people want client-side sieve editors to be able to hook into this. So the 
thoughts are not yet fully developed, and input would be very much welcome!

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20110531/604bd380/attachment.sig>