Make it possible to expose filters and pre-filters in the context procedure.

I just thought about another idea I posted before, which was about the rule that the SF settings overrule the context procedure.

In that case the most logical approach would be (possibly breaking a lot of existing applications) is that the context procedure gets the settings done in the SF and modifies them. 

It would actually possible not break to any scripts, as the Thinkwise standard is to hide, and the option to show was never available.

 

Hi @Daan Heemskerk,

I checked with some colleagues but we don't understand what you are trying to achieve. Can you please elaborate on this and provide some more context/examples/screenshots?

What I want to achieve is actually a bigger picture.

• I want to know what the users prefilters where so that I can restore them or do other things with them.
• If you know the pre filters you can make them empty buttons, and optimize the queries in another way. 
• To do this correctly you would need a browser tab session or client side logic, I explained this in another topic.

At this moment the biggest problem is that I found a way to switch between different variants of the same table, and to keep the users filter settings, but I don’t know the pre filter settings, so they are different on the different variants. I was looking at a way to synchronize this, and I can set them in the workflow, but I don’t know what they are … as I don’t know which prefilters the user selected I can’t make sure that they remain selected when a user switches to another tab or view.

In general I can set things like selected tabs and prefilters in the user interface, but I don’t know what the users selection was before. If you know that you can streamline the users experience.
 

Thank you for clarifying Daan, I will open your idea for votes. Perhaps this can become a part of some ideas we have about retrieving the current document state of the GUI.