[ingo] RFC: how to support custom sieve filters

[Jan Schneider]

Zitat von Ivan Sergio Borgonovo <mail at webthatworks.it>:

> I'd like to be able to write my custom sieve filters through a web
> interface and as well offer a GUI for less knowledgeable users.
>
> I'm not sure I could find the time to actually propose a patch and even
> before thinking about coding I'd like to have some feedback.
>
> While trying to understand how ingo works I ran into something that may
> be considered a bug.
>
> Ingo just read DB status ignoring what's the current managesieve status.
>
> So it may happen you disabled ingo filter from another program and
> without explicitly enabling it from the ingo interface, but just editing
> rules order you may accidentally enable again ingo filter and
> consequently disable your custom filter.
>
> And there is no way to revert this change if you just have web access to
> managesieve.

This is not a bug, but the consequence of Ingo not being a Sieve  
frontend, but an abstract filter frontend for different filter  
backends. It *must* store rules and states locally, and it won't work  
with any external provided scripts or changes.

> That aside it would be nice to have a way to be able to write custom
> filters from ingo web interface without renouncing to its GUI and to be
> able to enable/disable various script available on the server.
>
> Considering the current structure of the code and the DB it would
> require a large refactoring to actually be able to store more than one
> sieve filter in the DB.
>
> A possible solution could be to surround ingo generated script with some
> kind of delimiter and leave the rest of the script untouched.
>
> So ingo would load the content of a sieve script from the sieve server,
> replace or add its part of the script at the end of what it loaded,
> leave to the user the chance to edit it from the web and store it back
> on the server.
>
> This require very simple parsing of the stored sieve script and it is
> incompatible with just an extension I can think of: "global".
>
> require entries can be duplicated but global and include need a defined
> order.
>
> To make the whole thing usable I think there are at least some more
> details to fix:
> - additional permission to let user manually edit their filters

This won't happen for scripts generated by Ingo. I won't object  
against a new feature to edit other scripts from the server, in plain  
text.

> - check response of managesieve server to see if the script contained
> any error and report them

This is already happening

> - being able to select which filter to edit/add/activate among the one
> available on the sieve server

See item 1.

> If I've some spare time I think I could be able to implement most of the
> features I've described without the need to dig into ingo/horde API.
> What could be problematic without a deeper knowledge of horde internals
> would be to add permissions to manually edit filters.
>
>
>
> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it



-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject