[ingo] RFC: how to support custom sieve filters

[Ivan Sergio Borgonovo]

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 ;)
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.

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.

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.

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.

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.

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.

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.

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.

>> - 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?

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