BAC vs C:
Two of the investments held are Bank of America (BAC) and Citigroup (C). If a dividend comes from BAC, the description will be “BAC - Div on 5 000 Sh” for example (Share counts will differ). For C, it will be “C - Div on 5 000 Sh”. When it is “BAC - Div on 5 000 Sh”, the transaction is allocated to “Dividend Income - United States” and the division “BAC”. For C it will also be allocated to “Dividend Income - United States”, but to division “C”. However, before the update, it would pick up the c in “BAC - Div on 5 000 Sh” and allocate the transaction to the division “C” instead of “BAC”. The transaction for “C - Div on 5 000 Sh” would be handled correctly. This problem would be even worse where the conflicting stocks are in different jurisdictions, so for example if “C” was a company registered in Netherlands, it would have allocated “BAC - Div on 5 000 Sh” to “Dividend Income - Netherlands” with tracking code “C”. The fix has been that when “BAC - Div on 5 000 Sh” is matched to both “C - Div on” and “BAC - Div on” rules, it correctly picks up that the transaction relates to BAC not C.
Sorting
As for the dragging, as should be clear from all the description and screenshots I’ve posted, that is not how I use receipt/payment rules. That would not work for my case, because I need it to match to the correct account and division. That method would not allow me to dictate that “C - Div on” needs to be allocated to division “C” and “BAC - Div on” to division “BAC”.
The update fixed your rule priority order because Lubos customised Manager to your particular use case were one rules search string was completely repeated in the second rules search string. That is a very restrictive requirement and the only reason such a simple test works.
However given most users will not write or understand such rules the “solution” doesn’t really matter as long as it can be clearly explained to the few users who care.
Displaying the rules in what ever order Manager uses to prioritise them would achieve that.
Does the current solution (albeit maybe not for a problem you experienced) break something for you? I can’t see how this fix would have made the situation any worse for you or anyone else. Sure ordering them manually instead of the current fix may have been more convenient for you than this solution, but as explained, that is not even remotely scalable.
You are at best miss guided.
An ordered list is used for all complex searches because it is scalable. Inter related search terms can be grouped, priority easily and clearly set, enabling modular rule development.
If someone has 1,000 rules (I’m sure there are some with more than that), doing something like that is not scalable. What if there are clashes between rules that are not inter-related, rendering the grouping/modular development useless? And why should you have to dig through the hundreds of rules you have every time you add a new rule to look for potential clashes, to make sure it is sorted fine? And anyway, the modular development only works if you are developing from scratch. If your solution was implemented, I would have had to go back and basically re-do my hundreds of rules in order for the modular development to work.
You have yet to explain how the current fix makes it worse than before? What can your solution do that this solution does not already do? Other than you being able to visually see which order they are applied in, which would require close inspection to be useful in the first place when looking at hundreds of rules…