Exposing Grid's complete field list in Advanced Hilite Rule Target field

[senordhuff]

Hello,

We need to expose a ListGrid's complete field list in the Target Field drop-down and not just the visible fields.

Our application allows users to define highlights that can be applied to multiple views. So, they need to be able to build highlights based on the complete list of fields and not just those fields that happen to be visible in their current view.

I don't see any APIs that allow us to control this though. Any suggestions? Ideally, we could format the list to somehow distinguish between currently visible fields and those that are not currently visible.

[Isomorphic]

This seems an odd thing to do, as you would be creating a highlight with no immediate way to verify that it's working. It seems like that could only serve to confuse users.

So it's not really an option we think should be added, but if it's really valuable to you, we can make an exception and do it via Feature Sponsorship.

[senordhuff]

There is an immediate way to verify it is working. You apply the highlight and then the user can toggle between their various views after applying the highlights. We've customized our application so that highlights can be applied one time and applied to multiple views.

An end user is the one who asked for this. So, it is not coming out of nowhere. But, I've reviewed and patched your getClientOnlyFieldDS method for highlighting to allow for this already so no need for a feature sponsorship in this case.

[Isomorphic]

To clarify, whether we're talking about showing and hiding individual fields or switching to a new "view" that shows and hides whole sets of fields, we would still expect a user to switch to a view where the field is showing before attempting to apply a hilite to it.

Otherwise, again, they would have no way of seeing whether the hilite was working *until they showed the field*.

But it sounds like you have something that works for you, so we're just clarifying why it continues to seem like an undesirable thing for the framework.

[senordhuff]

Our users have

-1 set of highlights often for 30-40 different fields
-20-30 different views

We do not store highlight information with the views although I believe that is how your native viewstate functionality works.

As a result, any time they edit their 1 set of highlights, they are going to be making changes they cannot verify immediately because none of their views contain all of the fields they want to highlight. It is not practical to expect them to switch between views every time they are making a highlighting change. In fact, our users are configuring so many highlights that it isn't practical for them to take the time to even verify the highlights. They expect they can configure the highlights and it will work without visual verification. When configuring 30-40 highlights, it is already time consuming so verifying each one just gets skipped under the assumption that it will work.

Nor is it practical for them to remember the fields that are visible in each of their 30-40 views. I hope that makes sense and clarifies why this change is necessary for this usage. I'm guessing our usage is not typical for any of your other customers in this regard.

[Isomorphic]

That does clarify why you would have users creating highlights "blind" so to speak, but yeah, having 20-30 views of the same grid is atypical and seems to be the core reason why it is not easy to just make the fields you want to highlight visible before hilighting them.