allow javascript in the filter actions.

marking m15.

Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey bug tracking radar. Even though these bugs are not "open" in bugzilla, we welcome fixes and improvements in these areas at any time. Mail/news RFEs continue to be tracked on http://www.mozilla.org/mailnews/jobs.html

Reopen mail/news HELP WANTED bugs and reassign to nobody@mozilla.org

adding toshok to the cc list.

see http://devedge/docs/manuals/communicator/jsguide4/mail.htm for details. unlike 4.x, in 5.0 the rules file is the same across all platforms: rules.dat

Could somebody fix that link? It's invalid.

both links http://devedge/docs/manuals/communicator/jsguide4/mail.htm http://www.mozilla.org/mailnews/jobs.html work for me. what link isn't working?

Found it. You didn't put ".netscape.com" so I futzed around with devedge.com, .org, .net etc. I'm not entirely hip on all the Netscape lingo yet.

my fault. sorry about that. http://devedge.netscape.com/docs/manuals/communicator/jsguide4/mail.htm

JavaScript (with regular expressions) would be able to do amazing and powerful things as a message filter. Simply pass an email message object to a function in the script, with read-only members such as .Sender(), .From(), .CC(), .Subject(), perhaps even .Source(), and then decide an action based on its return value. Given all of the JavaScript-based cross-platform development going on anyway in this project, JS filters would seem at least within the realm of possibility.

"New" url: http://developer.netscape.com/docs/manuals/js/client/jsguide/mail.htm

Is this bug 4xp? Was that functionality present in Netscape Messenger 4?

Yes, the doc link in comment #11 refers to documentation for a feature that shipped in 4.x. /be

Bug 59341 is a dup of this one. Transfering deps. And check Bug 59341 comment #9 for more dups of this bug.

Actually nsMsgFilter contains code to attach a script to filter action, and it also saves it back (type="2" filters, I guess); but I don't understand where that code is actually called upon message receiving not where the actual filtering is done. I suppose that file only contains "residual" type-2 message filers from Netscape4 code?

Seems like there's been a long-standing typo here. Does nobody use News filters?

This was as far as I wanted a mail filter.. Very useful but never worked. Even more useful now with bounced virus in the thousands hitting my intray...

*** Bug 59341 has been marked as a duplicate of this bug. ***

Updating summary. Adding status whiteboard. We should discuss what access the script should have. Perhaps a security setting on the level of access such a script could have, such as filesystem (useful for writing emails to a log file) or chrome, or simply mailboxes.

*** Bug 330785 has been marked as a duplicate of this bug. ***

Comment on attachment 151438 [details] [diff] [review] Fix News filtertype definition there's no code to apply javascript filters so I don't think this change by itself will do anything.

Comment on attachment 151438 [details] [diff] [review] Fix News filtertype definition I'm not sure why would want this code, it doesn't give us JS filter actions anyway.

I can imagine having a filter action "Execute Skript", with a editable combobox for its values. You could either enter the code for a function in the textbox or choose from a list of registered functions (passed in from the frontend by registering respective callback functions). The function would be called with relevant data, like msgHdr or message body. Or what is this bug about?

I'm not sure of everyone else, but my interest is in filtering things that are "obvious" to me as a developer, but beyond the scope of simple =/!=/like filters. E.g. If I could run a RegEx (via JavaScript) on the subject line of an email... whereby if it started or ended with 4+ digits, then I would like to, because for me, this is a sure fire indicator of Spam. Likewise, the same ability on the body of the email, or the to: or the cc: list would be desired. I would be ecstatic with a filter type called 'script',... that would pass a single param to a function that you (the end user) supply, that simply returns true/false; if true, the msg meets the filter criteria... if false, it doesn't... So, for example: /* object msg .headers .body */ function mySpamFilter(msg){ if(msg.headers.Subject.length >= 50){ //likely spam... return true; } else if(msg.headers.Subject.indexOf(' wrote') != -1){ //spam-a-palooza return true; } else { //AFAIK, ATM, not spam return false; } } It may seem strange... but the idea is very cool, for those of us that would have a good idea as to what to do with it.

JFTR: URL of comment #11 as found in the WayBackMachine: <http://web.archive.org/web/20021219010440/http://developer.netscape.com/docs/manuals/js/client/jsguide/mail.htm>

> I would be ecstatic with a filter type called 'script',... that would pass a > single param to a function that you (the end user) supply, that simply returns > true/false; if true, the msg meets the filter criteria... if false, it > doesn't... This is exactly what this bug is *not* about. ;-) You're talking about <https://bugzilla.mozilla.org/show_bug.cgi?id=58407#c8>

@Karsten: I apologize then, I found this Bug#, when searching for the ability that was available in Netscape Comm. Mail 4.x. And since 58407 is marked "verified invalid", I suppose this is still the place to be. ;-)

perhaps this could be complimentary to bug 19442

Wayne suggested that a comment here might be appropriate for watchers: In TB 3.0 / SM 2.0 a new feature was added to allow arbitrary custom filter actions to be added by extensions. In my extension FiltaQuilla, one of the added filter actions is an arbitrary javascript filter action (javascript search is also available there). That does not directly affect the status of this bug, which remains a request to add this function in core. However, given its availability in an extension, and its fairly rare use there, the functionality of this bug is not likely to be added to core.

If someone has a patch and wants help with it then helpwanted is appropriate. That's not currently true afaict. Nix "helpwanted".