[ingo] RFC: how to support custom sieve filters

[Jan Schneider]

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

> On 08/29/2014 11:52 AM, Jan Schneider wrote:
>
>> Zitat von Ivan Sergio Borgonovo <mail at webthatworks.it>:
>
>>> 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.
>
> Let's say it is a very scary feature then ;)

Why? It's non-destructive.

> I'm aware that supporting many filter backends with a consistent
> frontend isn't an easy task.
> I'm wondering what is the use case.

Not having to develop different frontends for different scripting  
backends. And being able to switch between filter backends without  
losing rules.

> What's missing is the ability to manage (activate/deactivate) more than
> one script. This has no relationship with what ingo store in the DB and
> doesn't require ingo parse back what it finds in an alien script.
>
> If you just have web access and you unfortunately touch ANYTHING in ingo
> filter interface you may end up deactivating a perfectly working filter
> without any chance to activate it back.

I'd say it's not too much asked from a user to either use Ingo or  
create and manage their sieve scripts manually.

> But yeah other backends have no native concept of a set of available
> scripts.
>
>>> 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.
>
> I didn't get if you're against additional permissions to manually edit
> filters or you're against manually editing ingo generated filters.

The latter.

> For me both things are not essential.
>
> If you're against additional permission it is OK since my user base is
> my family.
>
> If I was a sysadmin, and I'm just an humble programmer I'd think twice
> to give everyone permission to manually edit its own filters. But I'm
> not a sysadmin, I don't work in such kind of environment so well that
> may not be an issue.
>
> If you're against letting people manually edit ingo generated filter...
> well it would be nice but I think there are other things I've to
> understand before even thinking about mixing ingo generated code and
> handwritten one. I've some hopes that once you let people manage more
> than one script and edit their own this could be solved with sieve include.

You can already use sieve includes in you manually created scripts and  
include the script generated by Ingo.

> So let be more concrete and let me know what's against the project policy.
>
> I'll turn the "Script" link into a "Scripts" link.
> There you'll see a list of scripts you could View, Activate and Edit.
> If you edit the ingo script (accordingly to what is set in the
> backends.local.php) you'll be redirected to the GUI. If you Edit another
> filter you get redirected to a TEXTAREA.

Yes, this is how it should work if it is ever going to be implemented.

> I can see in how many ways this is going to break the "common interface
> for all backends". Among all this would require turning on explicitly
> even ingo generated filter.

No, why, the default use case would still be the same. Beside that,  
you can already configure now if script changes should automatically  
or manually be uploaded.

> But this is the less intrusive way I could think of. If ingo is not
> going to support the idea of "managing" more than one script you'll have
> to introduce a much harder to understand and manage concept to switch
> from a hand written script to an ingo generated one: overwrite my
> handwritten script.
>
> Still I think that the chance of deactivating a perfectly running sieve
> script without any way to activate it back is pretty scary and have to
> be solved some way. I don't think this can be solved without introducing
> at least for the sieve filter frontend the concept of multiple scripts.

Don't let users use Ingo, if they already use some other tool to  
manage their scripts.

> How you abstracted filters across different backends is laudable but I
> can't see any way to go further without some minor divergences in UI
> across different backends.

I never said this wasn't possible, and the UI already adapts  
automatically to the features of the configured backend.

>>> - being able to select which filter to edit/add/activate among the one
>>> available on the sieve server
>
>> See item 1.
>
> I didn't get what you mean. So is the project policy "the frontend has
> to be absolutely identical for all backends"? Why?

No, but the answer is the same like to item 1. Ingo was never designed  
to manage any scripts other than Ingo's. It's a sieve frontend, not a  
managesieve frontend.

> I'm trying to guess if what I need is what people in the project may
> want to include and get an idea if it is feasible.
>
> thanks
>
> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>
>
> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it



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