Hi Pim! As you can seein previous mails on this list, RC internal filters are not very much popular ;D, but I've coded on the first filters version, easily upgradable to the new ones. It's a list decision. If this a possibility and not the only solution (as you sat) may be is a better way accepted by everyone.
Regards, emi El Vie, 11 de Enero de 2008, 20:23, Pim Vullers escribió: > I really like the idea of filters in Roundcube. I love them in > Thunderbird. > > > But what about 'native' filter support for RC? For example make it > possible to choose the server filtering mechanism, but also make it > possible that RC itself filters the messages. As for example I use RC for > mailaccess to my IMAP account at my hosting provider. However I do not > control the server such that I don't have access to the server > configuration and so on, which means that my client applications will have > to do the filtering. > > Have there been any thoughts about things like this? > > > Kind regards, > Pim > > > chris# wrote: >> On Thu, 10 Jan 2008 19:19:42 +0100, "emi delg" <[EMAIL PROTECTED]> >> wrote: >> >>> Hi Javier and Chris!! >>> Javier: >>> 1.- Sorry, the translator script is a shell script written in PHP (to >>> take the db info and rest). It's easy to make a UI (frontend) for >>> this. 2.- What is RPC? >>> >> >> Remote Procedure Call >> Often used in an XMLRPC form as well. >> >> >>> 3.- That's a good idea to make them compatible, but structured >>> filtering is not just ordered filtering. I mean: we should work on >>> improving the old UI to be able to create what the new one can: reply, >>> forward, delete, copy and if/else. Copy and if/else are the most >>> complicated features to develop on the text UI, because these have 2 >>> possibilities after them. >>> >>> Chris: >>> 1.- RoundCube have to know which is the end filtering system because >>> probably not all of them have all the features (actual and future), so >>> you (as mail admin) will need to block some of the features. For sure >>> this is a config issue. >> >> I can see easily where RC could parse and ini file to obtain the >> /current/ feature >> set for all supported filters. That would make very easy to to produce a >> form with checkboxes to enable/disable grouped and or individual >> options/features. The rest, of course would be up to the admin - >> providing user-based, or global options. >> >>> ¿Are we able to make an admin entrance to enable RC administration >>> via web? >> >> Yes, quite easily. >> if !isset admin, read-most else readall >> >>> It would be great!! >>> >> >> Indeed. >> >> >>> 2.- Every mail system has it's own and very different working method. >>> You >>> can have, for example, a DB based users auth or just a Linux users >>> auth, IMAP on a server and RC on another one and LDAP auth on a third >>> one, etc You >>> can configure each of the filtering system nearly as you want, so it's >>> difficult for RC to do all the work. What I mean is that mail >>> configuration is nearly chaotic to improve all the possibilities. Due >>> to this issue, we can think on an intermediate solution, which, for >>> example, lets the admin to create the scripts that will be executed by >>> RC automatically to save the >>> filters on the right way. >> >> See my comment above. >> >> >>> 2008/1/10, J. Javier Maestro <[EMAIL PROTECTED]>: >>> >>>> On Jan Thu 10 2008 18:19, emi delg wrote: >>>> >>>>> Hi Javier!! >>>>> The simpler filters UI is testable at https://mail.cio.cat with >>>>> same >>>> user >>>>> and passwd. >>>> Cool, I'll have a look at it as soon as I have some free time. >>>> >>>> >>>>> May be we can add both UIs and let the user/admin decide whether >>>>> to >>> use >>>> one >>>>> or the other. >>>> I think the best model would be something like: >>>> >>>> >>>> - Let the basic, text-based UI form be the default >>>> >>>> >>>> - This should use the usual .inc functions in program/steps, >>>> broken in (duh!) simple steps such as save_filter.inc, >>>> translate_filter.inc, etc. >>>> >>>> - Finally, the graphic UI should construct the same textual info >>>> from the text-UI but using the graphic UI, and then pass it to the >>>> same step .inc files from the textual UI. >>>> >>>> - The .inc in steps/ should be doing the translation in PHP... >>>> doing it in a bash script is OK, but I think integrating it into PHP >>>> would be better). Then, they should send this maildrop, procmail, >>>> whatever filter to a central server through RPC, to >>> incorporate >>>> it in the user mail-flow, etc. >>>> >>>> >>>> -- >>>> J. Javier Maestro <[EMAIL PROTECTED]> >>>> Socio Consultor - Nosys AJjV S.L. >>>> >>>> >> ///////////////////////////////////////////////////// >> Service provided by hitOmeter.NET internet messaging! >> . >> >> >> >> _______________________________________________ >> List info: http://lists.roundcube.net/dev/ >> > > > -- > Pim Vullers > Heerstraat 29 / 5953 GE Reuver > [EMAIL PROTECTED] > > > > > --- 8< --- detachments --- 8< --- > The following attachments have been detached and are available for > viewing. http://detached.gigo.com/rc/D5/7saVCTo8/signature.asc > Only click these links if you trust the sender, as well as this message. > --- 8< --- detachments --- 8< --- > > > _______________________________________________ > List info: http://lists.roundcube.net/dev/ > > _______________________________________________ List info: http://lists.roundcube.net/dev/
