Stop automatically adding parenthesis to filter logic in report builder
Recently (possibly with the switch to HA reporting), the report builder has started automatically adding outside parenthesis to filter logic statements. This is unnecessary, and when I need to add specific subclauses I have to go in and clean it up.
Example: A AND B AND C is saved as (A AND B AND C) - the parenthesis don’t serve any purpose.
I would like to add a D OR E subclause to the logic. So I put the new filters in place, and need to end up with A AND B AND C AND (D OR E). I’ve got to go clean up the automatically-added parenthesis, which never did anything anyway. It would be more convenient if those weren’t added in the first place.
Page 1 / 1
A and B = (A and but the ( ) adds unnecessary characters when trying to make simple changes. For us admins who have been doing this for years at this point and have that muscle memory, throwing in a few more characters impacts our workflows HUGELY.
Hello @TMaier, thank you for posting on Community, looping in our Product Manager to look into this and get back to you.
good call out @TMaier
I agree seems to be weird once the logic grows big.
Alternative would be to follow what most IDE’s in the world do put a closing parenthesis once a new one is opened it keeps the subclauses intact and also prevents people from having to remember to close them out .. ?
Thoughts ? @gunjanm@bradley@TMaier
Azad, unless my memory is way off the old system just didn’t automatically add parenthesis at all - it was on the user to define those if they were needed. It seems cleaner and easier to return to that method because the only time parenthesis would be relevant is when a subclause is required and then I’d already be defining it with the required parenthesis.
If you were to automatically add parenthesis in any way, the problem you’d face is correctly predicting the user’s intentions which seems tough. Leave that to us.
@TMaier - my suggestion was to only add the closing parenthesis by default when you open one so that it’s easier to know when you form a sub clause
We would remove the parenthesis that exist today that do not add value ..
How would you know where to add the closing parenthesis? At the end of the entire statement would be my assumption, but that gets wacky if I edit logic to create subclasses anywhere before the end and close it myself.
I assume that the automatic addition is only made when the user saves their logic, which means it won't be visible in real-time and I think that would lead to even more confusion.
@TMaier - Here is the example - There are three things happening here
There are no unneccessary parenthesis being added
As soon as you Open a parenthesis the cursor move ahead one step to allow you to start typing in the sub clause space
A closed parenthesis is also added right after your cursor moves ahead so that you do not have to add one yourself.
That looks good, except in instances where I am editing existing logic - how would it handle that?
@Azad it would probably be better to let the Admin determine the logic rather than have the tool try to make assumptions. Nothing irritates me quite as much as when I am trying to create or modify an asset and it makes an assumption that does not match my intention.
@TMaier - Here is the example - There are three things happening here
There are no unneccessary parenthesis being added
As soon as you Open a parenthesis the cursor move ahead one step to allow you to start typing in the sub clause space
A closed parenthesis is also added right after your cursor moves ahead so that you do not have to add one yourself.
When Gainsight allows us to write actual code, having a plug-in to Atom Text editor would be great as that could to the heavy lifting, and has tons of customization on automatically closing brackets, customizing common things, etc. However, writing out Gainsight logic is a bit fiddley as it is as we’re limited to AND and Or statements in one line, so predictively adding this as @darkknight and @TMaier has pointed out will be an overcomplication that will create more problems than it solves.
A simple validation on save noting that a pair isn’t closed is really all that’s needed, which was what we already had. @Azad
@bradley - the team is looking into modifying this behaviour.
@Azad Any update on this? It isn’t limited to HA dashboards, but shows up in rules and pretty much everywhere and is actually anti-helpful.
@anirbandutta this continues to vex me in every area of the platform trying to update complex logic, is this still being looked at or considered?
@Prateek Parashar would you be able to share where we are at with this?
Could we please get an update on this? Would be AWESOME if this could come to Horizon features across the product.
@revathimenon T_T
Here’s an actual example of how dangerous this behavior can be. If I had not reviewed and corrected this issue, I’d have introduced bad config to this rule - what I NEED is “(A OR AND C” but when adding C we get the following…
Before...
After adding C…
Here’s an actual example of how dangerous this behavior can be. If I had not reviewed and corrected this issue, I’d have introduced bad config to this rule - what I NEED is “(A OR AND C” but when adding C we get the following…
If you ever had a profile with us, there's no need to create another one. Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
but the ( ) adds unnecessary characters when trying to make simple changes. For us admins who have been doing this for years at this point and have that muscle memory, throwing in a few more characters impacts our workflows HUGELY. 
