Quote:
Originally Posted by JeremyNicoll
I have hundreds of rules in each system, and neither is particularly good at managing big lists of rules, but it is possible. With the RC ones, the rules are stored in name order so the rule names not only have to mean something to you but also the order they'll be considered in.
|
Considering how often I define rules under RoundCube it's truly amazing that what I wrote there was wrong! RC does not store its rules in alphabetical order by name - one has to drag them into a desired order.
My mind-fart was because I choose to keep my rules in alphabetic order by name. The rule name is a required part of any rule (unlike FM where rule names are optional).
What /is/ perhaps annoying about RC is that child folders of a parent folder are automatically placed in alphabetical order (and you can't change that so far as I can see), so eg you cannot have
Various animals
|
+- Snakes
+- Quadrapeds
+- Bipeds
but instead will be forced to have
Various animals
|
+- Bipeds
+- Quadrapeds
+- Snakes
(though of course you can drag child folders to make them children of different parents. You can also just click on a folder and in its properties display change its parent from a drop-down list).
On my system I have a naming convention for both the child folders and their parents that fits in with the naming convention I have for my hundreds of mail aliases. When I define filters I name them according to the folder they place mails into ... and they are processed in folder order so appear in alphabetic order in the list of filters.
The version of RC I get access to now - v1.3.16 - has an annoying bug, and also a feature I don't like, which make dragging rules around a pain. It's the fact that I'm all too aware of this pain that makes me wonder today why I wrote the rubbish above...
The feature I don't like is that after one has dragged a rule to a new place (only within the current displayed screenful of rules - it won't autoscroll to show you more places where you could end the drag) the whole list of rules is redrawn and it's shown again from the top. (Compare that to FM's rule dragger where the display updates as you drag and never resets to the top.) As new rules get added at the foot of the list that means if one is trying to position a rule near the top one has repeatedly to do a drag part of the way up, find oneself at the top of a new display, scroll down to find the rule one was dragging (fortunately it is usually shown in bold), position the screen view optimally, then drag it a bit more ... and repeat.
The bug is that in my recent experience just clicking and holding on the highlighted rule when one has scrolled-down looking for it after a prior drag doesn't always register properly. Sometimes RC then somehow loses it; in particular it loses its highlight and you have to go looking for it in a redrawn list of rules again. And this time, you need to have remembered approximately where you had dragged it to because it will no longer be highlighted. To get around this I have found that when I scroll down to a highlighted rule, I deliberately click on an adjacent (unhighlighted rule) then when that registers I click on the one I want to drag, then drag it. That (currently) seems more reliable.
As I have hundreds of rules and my wide but not high laptop screen only shows about 18 of them at a time, I normally reduce the screen zoom quite a lot before dragging a rule around. That of course makes each one a lot smaller and is perhaps part of the unregistering-click problem, but when it works it means I can drag a rule 40 or so places at a time, which halfs the number of drags required.
A couple of times in recent weeks I have the impression that the dragging logic has got completely confused and have had to exit from the rules display and go back into it.
You might find that your mail provider does not run a particularly recent version of RC and (maybe worse?) might not update it very often.