Hi everyone!! First of all, my old email address (emi@algorismia.com) is temporally out, so I write from here.
I've working on filters UI. I don't send the patch because I've not updated (yet) the sql2filter php script. And I also want opinions, recomendations, etc.
You can see the working new filters UI at: URL: http://rcdev2.cio.cat User: rcdev Passw: rcdev
Instructions:
- The dropareas are the empty squares
- Dragg'n'drop objects to change their position
- Dragg'n'drop the buttons to add objects to the filter
- Double click on an object to edit it's data
- Doubleclick again or press ENTER to save it, or ESC to cancel changes
Todo list:
- Delete object (filter node)
- Control the 'too much recursion' JavaScript error
- Insert between function, to insert an object between other two
- Klipper area, where you can leave objects temporally
- "IFrameize" the WorkArea
- Scroll when needed
- Make a better positioning rules (try to create a 6 levels filter)
- Make a better Condition editing
- Control the data inserted on objects (valid email address, ...)
- Use an HTML editor for Reply objects
- Use data from addressbook, saved messages, etc to create/edit objects
If someone wants the patch to help coding, just tell me.
Waiting foe your comments, emi
List info: http://lists.roundcube.net/dev/
Hey Emi!
On Jan 10, 2008 3:46 PM, emi delg emidaruma@gmail.com wrote:
(...) You can see the working new filters UI at: URL: http://rcdev2.cio.cat
Can you check that URL again? ;-)
(...)
Cheers, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Sorry!! the correct URL is https://rcdev2.cio.cat (add the 's' to http)
2008/1/10, till klimpong@gmail.com:
Hey Emi!
On Jan 10, 2008 3:46 PM, emi delg emidaruma@gmail.com wrote:
(...) You can see the working new filters UI at: URL: http://rcdev2.cio.cat
Can you check that URL again? ;-)
(...)
Cheers, Till
List info: http://lists.roundcube.net/dev/
On Jan 10, 2008 4:05 PM, emi delg emidaruma@gmail.com wrote:
Sorry!! the correct URL is https://rcdev2.cio.cat (add the 's' to http)
Much better - now this: DB Error in /home/emi/trunk2/roundcubemail/program/include/rcube_db.inc (521): DB Error: no such field Query: SELECT * FROM filters WHERE user_id=6 ORDER BY position [nativecode=1054 ** Unknown column 'position' in 'order clause']
Warning: Cannot modify header information - headers already sent in /home/emi/trunk2/roundcubemail/program/include/rcube_html.inc on line 163
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Yep. Now it's ok. This error was coming from the previous filters UI I did. Try again and tell.
Sorry for the unfructuous proves :^)
2008/1/10, till klimpong@gmail.com:
On Jan 10, 2008 4:05 PM, emi delg emidaruma@gmail.com wrote:
Sorry!! the correct URL is https://rcdev2.cio.cat (add the 's' to http)
Much better - now this: DB Error in /home/emi/trunk2/roundcubemail/program/include/rcube_db.inc (521): DB Error: no such field Query: SELECT * FROM filters WHERE user_id=6 ORDER BY position [nativecode=1054 ** Unknown column 'position' in 'order clause']
Warning: Cannot modify header information - headers already sent in /home/emi/trunk2/roundcubemail/program/include/rcube_html.inc on line 163
Till
List info: http://lists.roundcube.net/dev/
On Jan 10, 2008 4:52 PM, emi delg emidaruma@gmail.com wrote:
Yep. Now it's ok. This error was coming from the previous filters UI I did. Try again and tell.
Sorry for the unfructuous proves :^)
Pretty interesting. Good idea to use icons. Of course the icons should "match" the theme a tad better, but generally why not. Wonder what others think.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I took the icons from KDE artwork (thanks GPL) Think: I'm not a graphical artist 8^)
About icons and styles, I did it in the first way it came to me. I'm sure it will be changed before getting inside trunk. For example, the red border of the editing box is... ¿ugly?
Yep: Styles are also on the TODO list (and icons are part of the css).
2008/1/10, till klimpong@gmail.com:
On Jan 10, 2008 4:52 PM, emi delg emidaruma@gmail.com wrote:
Yep. Now it's ok. This error was coming from the previous filters UI I did. Try again and tell.
Sorry for the unfructuous proves :^)
Pretty interesting. Good idea to use icons. Of course the icons should "match" the theme a tad better, but generally why not. Wonder what others think.
Till
List info: http://lists.roundcube.net/dev/
On Jan Thu 10 2008 17:04, till wrote:
On Jan 10, 2008 4:52 PM, emi delg emidaruma@gmail.com wrote:
Pretty interesting. Good idea to use icons. Of course the icons should "match" the theme a tad better, but generally why not. Wonder what others think.
I find it pretty cool :) In any case, I would first do a "text-based" filter UI, "a la gmail", where creating filters by form-filling is easy too.
Now, since I am new to the list and I haven't had the time yet to check all the mail archive, I might be talking out of my ass here; if so, simply skip the mail to the end, please 8)
This is a UI, so I guess there must be a backend. However, I don't think that RC should do any mail filtering. It should allow to *manage* filtering rules stored in (and used by) the mail server, "a la maildrop" filters, where manage would mean create too, of course.
But, again, I think this should be done through RPC, by using some web service that controls the mail server, filter creation, etc. This way, RC would manage/create/delete filters and send the manage/create/delete petition to the RPC server that would actually apply it to the user's mail flow, etc.
In any case, your work is a cool, awesome idea :D :D
My 2 cents!
Hi Javier!! The simpler filters UI is testable at https://mail.cio.cat with same user and passwd. May be we can add both UIs and let the user/admin decide whether to use one or the other.
About the backend, it's a bash script that takes all filters objects and translates them to the server specific filtering system (maildrop, sieve, exim, ...). That script have to be run by the mail admin, who'll place the output into the files used by the filtering system.
May be we can create an admin entrance to be able to configure RC from the web, and also take the files from filters, etc.
2008/1/10, J. Javier Maestro roundcube-devel@nosys.es:
On Jan Thu 10 2008 17:04, till wrote:
On Jan 10, 2008 4:52 PM, emi delg emidaruma@gmail.com wrote:
Pretty interesting. Good idea to use icons. Of course the icons should "match" the theme a tad better, but generally why not. Wonder what others think.
I find it pretty cool :) In any case, I would first do a "text-based" filter UI, "a la gmail", where creating filters by form-filling is easy too.
Now, since I am new to the list and I haven't had the time yet to check all the mail archive, I might be talking out of my ass here; if so, simply skip the mail to the end, please 8)
This is a UI, so I guess there must be a backend. However, I don't think that RC should do any mail filtering. It should allow to *manage* filtering rules stored in (and used by) the mail server, "a la maildrop" filters, where manage would mean create too, of course.
But, again, I think this should be done through RPC, by using some web service that controls the mail server, filter creation, etc. This way, RC would manage/create/delete filters and send the manage/create/delete petition to the RPC server that would actually apply it to the user's mail flow, etc.
In any case, your work is a cool, awesome idea :D :D
My 2 cents!
-- J. Javier Maestro jjmaestro@nosys.es Socio Consultor - Nosys AJjV S.L.
List info: http://lists.roundcube.net/dev/
On Thu, 10 Jan 2008 18:19:10 +0100, "emi delg" emidaruma@gmail.com wrote:
Hi Javier!! The simpler filters UI is testable at https://mail.cio.cat with same user and passwd. May be we can add both UIs and let the user/admin decide whether to use one or the other.
About the backend, it's a bash script that takes all filters objects and translates them to the server specific filtering system (maildrop, sieve, exim, ...). That script have to be run by the mail admin, who'll place the output into the files used by the filtering system.
That sounds labor intensive. :(
May be we can create an admin entrance to be able to configure RC from the web, and also take the files from filters, etc.
This sounds like a smarter approach. Perhaps the best solution would be to allow the admin to decide which filtering type is available to the end users - eg; maildrop, sieve, exim... Because that's really all that needs to be required. That way the right rules will be created for the server it's running on/ talking to.
2008/1/10, J. Javier Maestro roundcube-devel@nosys.es:
On Jan Thu 10 2008 17:04, till wrote:
On Jan 10, 2008 4:52 PM, emi delg emidaruma@gmail.com wrote:
Pretty interesting. Good idea to use icons. Of course the icons should "match" the theme a tad better, but generally why not. Wonder what others think.
I find it pretty cool :) In any case, I would first do a "text-based" filter UI, "a la gmail", where creating filters by form-filling is easy too.
Now, since I am new to the list and I haven't had the time yet to check all the mail archive, I might be talking out of my ass here; if so, simply skip the mail to the end, please 8)
This is a UI, so I guess there must be a backend. However, I don't think that RC should do any mail filtering. It should allow to *manage* filtering rules stored in (and used by) the mail server, "a la maildrop" filters, where manage would mean create too, of course.
But, again, I think this should be done through RPC, by using some web service that controls the mail server, filter creation, etc. This way,
RC
would manage/create/delete filters and send the manage/create/delete petition to the RPC server that would actually apply it to the user's mail flow, etc.
In any case, your work is a cool, awesome idea :D :D
My 2 cents!
-- J. Javier Maestro jjmaestro@nosys.es Socio Consultor - Nosys AJjV S.L.
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
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.
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? 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. ¿Are we able to make an admin entrance to enable RC administration via web? It would be great!!
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.
2008/1/10, J. Javier Maestro roundcube-devel@nosys.es:
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 infofrom 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 jjmaestro@nosys.es Socio Consultor - Nosys AJjV S.L.
List info: http://lists.roundcube.net/dev/
On Thu, 10 Jan 2008 19:19:42 +0100, "emi delg" emidaruma@gmail.com 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 roundcube-devel@nosys.es:
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 infofrom 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 jjmaestro@nosys.es Socio Consultor - Nosys AJjV S.L.
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
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" emidaruma@gmail.com 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 roundcube-devel@nosys.es:
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 infofrom 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 jjmaestro@nosys.es Socio Consultor - Nosys AJjV S.L.
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
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" emidaruma@gmail.com 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 roundcube-devel@nosys.es:
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 jjmaestro@nosys.es 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 pim@vullersmail.nl
--- 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/
Thanks, it is some time ago that I subscribed and followed the list frequently. During the plugin discussion and about rewrite of the communication with the server. But due to a higher workload I now and then scroll through the messages and read the ones with interresting subjects. And this one looked interesting ;)
emi@algorismia.com wrote:
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" emidaruma@gmail.com 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 roundcube-devel@nosys.es:
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 jjmaestro@nosys.es 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 pim@vullersmail.nl
--- 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/
On Jan Fri 11 2008 20:23, Pim Vullers wrote:
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.
Then, I guess the best compromise is a source-independent architecture. Something along this line:
- RC should implement its own filtering system. For the sake of
discussion, the filter should be very close to at least one of the
mostly used filtering programs (maildrop, procmail, etc).
- RC should be able to import/export filters, via RPC, translating
from a few filter types (again, the usual suspects).
. When importing filters, RC would translate them to its filtering
type, and let them stay still doing nothing until activated.
- When exporting, it should simply translate the filter to the
selected type and push it through RPC to the server, where the RPC
script will most surely know what to do with it.
This way, RC would be able to manage the filters in the server, import them if the user wants to change the server but keep using the same filters (in the client), etc.
My 2 cents :)
Hi everybody! I've been implementing some of the TODO items:
- JavaScript 'Too much recursion' error (which was very annoying)
- Page scrolling (wow! IE is worst than I thought, and I thought very bad!)
- Delete droparea
Actual TODO list
UI:
- Insert between function, to insert an object between other two
- Klipper area, where you can leave objects temporally
- "IFrameize" the WorkArea
- Make a better positioning rules (try to create a 6 levels filter)
- Make a better Condition editing
- Control the data inserted on objects (valid email address, ...)
- Use an HTML editor for Reply objects
Functionality:
- Use data from addressbook, saved messages, etc. to create/edit objects
- RC should implement its own filtering system. For the sake of discussion, the filter should be very close to at least one of the mostly used filtering programs (maildrop, procmail, etc).
- RC should be able to import/export filters, via RPC, translating from a few filter types (again, the usual suspects). . When importing filters, RC would translate them to its filtering type, and let them stay still doing nothing until activated.
- When exporting, it should simply translate the filter to the selected type and push it through RPC to the server, where the RPC script will most surely know what to do with it.
See you very soon!
emi
El Jue, 10 de Enero de 2008, 15:46, emi delg escribió:
Hi everyone!! First of all, my old email address (emi@algorismia.com) is temporally out, so I write from here.
I've working on filters UI. I don't send the patch because I've not updated (yet) the sql2filter php script. And I also want opinions, recomendations, etc.
You can see the working new filters UI at: URL: https://rcdev2.cio.cat User: rcdev Passw: rcdev
Instructions:
- The dropareas are the empty squares
- Dragg'n'drop objects to change their position
- Dragg'n'drop the buttons to add objects to the filter
- Double click on an object to edit it's data
- Doubleclick again or press ENTER to save it, or ESC to cancel changes
Todo list:
- Delete object (filter node)
- Control the 'too much recursion' JavaScript error
- Insert between function, to insert an object between other two
- Klipper area, where you can leave objects temporally
- "IFrameize" the WorkArea
- Scroll when needed
- Make a better positioning rules (try to create a 6 levels filter)
- Make a better Condition editing
- Control the data inserted on objects (valid email address, ...)
- Use an HTML editor for Reply objects
- Use data from addressbook, saved messages, etc to create/edit objects
If someone wants the patch to help coding, just tell me.
Waiting foe your comments, emi _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
-
chris# -
emi delg -
emi＠algorismia.com -
J. Javier Maestro -
Pim Vullers -
till