|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
25 Mar 2020, 01:42 AM | #1 | |
The "e" in e-mail
Join Date: Apr 2011
Location: Manchester UK
Posts: 2,616
|
Filters sort and mark mail how you want
From the Fastmail blog:
https://fastmail.blog/2020/03/23/ema...ation-filters/ Quote:
|
|
25 Mar 2020, 07:53 AM | #2 |
Cornerstone of the Community
Join Date: Jun 2008
Location: Perth
Posts: 664
|
Interesting. It all sounds good. Especially the bit about being able to forward emails after a search.
But - it looks like it requires an "upgrade" button to be pushed in the settings menu. My questions are: i) what functionality is lost if one selects the rules upgrade, and ii) is the rule upgrade process reversible? |
25 Mar 2020, 08:33 AM | #3 |
Essential Contributor
Join Date: Mar 2007
Location: UK
Posts: 270
|
Since there is no mention of it, I would add
iii) Can we still use Sieve script if we upgrade? |
25 Mar 2020, 01:32 PM | #4 |
Essential Contributor
Join Date: May 2018
Posts: 478
|
I was playing around with this stuff for the last two or three weeks now so I think I have some of the answers.
Functionality lost? None as far as I can tell. But if you use Sieve it won't (apparently as of today) you can't turn on the new rules stuff. I think they are worried that their new way of handling rules in sieve can cause syntax errors with existing user-written sieve code. As best as I can tell only with any code that might be in the last user edit block. For example the old rules stuff was a series of elsif blocks. Not any more. So if the last edit block continues on with an elsif it's an uncaught syntax error. It will be caught if you create or change a rule. But if not I don't know what happens at run time when an invalid sieve script is executed. I never got that far in my initial testing because create a new rule does do a syntax check and I do have code in that last edit block that started with an elsif. I now precede that code I added with a test of all the possible switches (variables) the new FM-generated rules code now use. Early in my testing I submitted a ticket on this potential problem and now it comes back to bite me in the form that I can no long enable/disable the old and new rules stuff. I disabled it to see if I could enable in in the release so now I'm locked out. At any rate, from a UI point of view no old functionality appears to be lost. There are some UI inconveniences to create a rule though since they added the ability to test a rule. is the rule upgrade process reversible? If you don't have any of your own sieve code, at the moment, yes. They way it has worked up till now is you could enable/disable it from beta.fastmail.com. Since I can no longer enable it from either because I have sieve code I don't know if there is a disable in the release version. Can we still use Sieve script if we upgrade? As of today, beats me. They won't even allow you to test the new rules stuff if you have sieve additions in either release or beta. Sieve was one of the primary reasons I switched to FM. If we can't use it what's the point? If no user sieve, they don't need sieve tester either. One less thing for them to support -- what little support they ever do on it anyhow. IMO all they need to do is add a syntax check when the new rules stuff is enabled and report an appropriate error at that time. |
25 Mar 2020, 06:59 PM | #5 |
Junior Member
Join Date: Jul 2016
Posts: 23
|
On twitter they answered Sieve will stay: https://twitter.com/Fastmail/status/1242638419228078086
|
26 Mar 2020, 01:24 AM | #6 |
Cornerstone of the Community
Join Date: Jan 2003
Location: Oxfordshire, UK
Posts: 603
|
yes, it's using if and stop (rather than if and elseif)
but written in a way that seems more complex than necessary: set "stop" "Y"; and if allof( not string :is "${stop}" "Y", I have always just written: stop; |
26 Mar 2020, 03:45 AM | #7 |
Essential Contributor
Join Date: May 2018
Posts: 478
|
The "stop" they are testing is a variable set earlier to indicate further down that execution is to stop after some additional action. But the code is not ready to stop execution at the point they set it.
Here's the tests I inserted at the beginning of the last edit block before my additional code... Code:
if anyof(string :is ["${stop}", "${skipinbox}", "${hasmailbox}", "${deletetotrash}", "${spam}"] "Y", exists "X-LinkId") { stop; } IMO, it's a shame they didn't "sprinkle" a few underscores in their switch names to help reduce possible naming conflicts with identifiers the user might use in their own code. I submitted a ticket last night requesting they allow me to turn the new rules stuff back on. ---- Update: I looked at a copy of the last time I updated my sieve code (I always save a copy) and I noticed they had added the following just before the last edit block (at the end of section 6), Code:
if string :is "${stop}" "Y" { # For backwards compatibility } Last edited by xyzzy : 26 Mar 2020 at 07:37 AM. |