EmailDiscussions.com - View Single Post

JeremyNicoll · 21 Aug 2019, 08:42 PM

FM support replied, first saying:

-------------------------------------------------------------------------------------------
So, the alias search change was actually intentional. Basically, we have a function that transforms the search text into a regular expression for searching; there were a few settings pages where the search was not using this function, aliases screen being one of them. They have now been updated to match. The function matches different types of internationalised characters (so you could type "e" to match "é" for example) and it automatically only matches starting from word boundaries. This is consistent with our mail search behavior.

However, in July our developers have extended this to allow "*" for glob style matching which would allow you to match anywhere by typing * first and then the string you want to search. This means you can now search for "*<word>" replacing "<word>" with the sub-string one that you are looking for.
-------------------------------------------------------------------------------------------

I thought the first part of that was largely irrelevant, and said so:

Is there any point in supporting international
characters? Are they legal in alias values? How could
anyone send an email to: café@domain ?

and also:

Why is there no help information available directly from
the panel concerned explaining how his works?

to which they have replied:

-------------------------------------------------------------------------------------------
Yes, email address with non English character is currently not valid.
So, thats not helpful for the aliases screen. However, the main
purpose was to use the same search function everywhere for consistency.

I'll add an internal task for our documentation team so this can be addressed. Thanks for the feedback.
-------------------------------------------------------------------------------------------

I've replied:

As for 'consistency'. I'm not convinced. There's a big difference between users searching reams of unformatted text vv what they need when filtering lines which simply contain single 'words' (in the sense of them being strings of characters not containing whitespace). Forcing the alias display filtering code to use logic that doesn't fit with what's being filtered - AND is difficult to understand without the help you haven't yet written AND is less useful than the code that was there before, is a backward step.

I think you should simply go back to the filtering code you used to have and label the parameter field "Filter:" rather than "Search:".

21 Aug 2019, 08:42 PM	#31
JeremyNicoll Essential Contributor Join Date: Dec 2017 Location: Scotland Posts: 484	FM support replied, first saying: ------------------------------------------------------------------------------------------- So, the alias search change was actually intentional. Basically, we have a function that transforms the search text into a regular expression for searching; there were a few settings pages where the search was not using this function, aliases screen being one of them. They have now been updated to match. The function matches different types of internationalised characters (so you could type "e" to match "é" for example) and it automatically only matches starting from word boundaries. This is consistent with our mail search behavior. However, in July our developers have extended this to allow "" for glob style matching which would allow you to match anywhere by typing first and then the string you want to search. This means you can now search for "*<word>" replacing "<word>" with the sub-string one that you are looking for. ------------------------------------------------------------------------------------------- I thought the first part of that was largely irrelevant, and said so: Is there any point in supporting international characters? Are they legal in alias values? How could anyone send an email to: café@domain ? and also: Why is there no help information available directly from the panel concerned explaining how his works? to which they have replied: ------------------------------------------------------------------------------------------- Yes, email address with non English character is currently not valid. So, thats not helpful for the aliases screen. However, the main purpose was to use the same search function everywhere for consistency. I'll add an internal task for our documentation team so this can be addressed. Thanks for the feedback. ------------------------------------------------------------------------------------------- I've replied: As for 'consistency'. I'm not convinced. There's a big difference between users searching reams of unformatted text vv what they need when filtering lines which simply contain single 'words' (in the sense of them being strings of characters not containing whitespace). Forcing the alias display filtering code to use logic that doesn't fit with what's being filtered - AND is difficult to understand without the help you haven't yet written AND is less useful than the code that was there before, is a backward step. I think you should simply go back to the filtering code you used to have and label the parameter field "Filter:" rather than "Search:".