Users are losing filters when they go back to the reports.

Why don't we save the filter settings in a dictionary that is converted to JSON text and saved to DB when the user clicks the "Save" link. This way any SAIL component could store its data and we only need a single DB query to load the settings. fromJson() converts it back to a normal Appian dictionary. See attached code for an idea.

Actually I have a problem with this code. When there is a single SAIL Component, dropdown OR radiobuttons, the selected value gets saved to the dictionary. As soon as I add the other one, it does not work anymore. To be more specific, as I try to access the dictionary in the "value" property it stops working.

Maybe we can work together to get this sorted out. Would be a very nice feature to add to our toolbox.

filterSettings.txt

I agree, we will be taking a look at it this week as its getting quite frustrating for the users so it will be anice Christmas present for them :)

We will post up what we have done by the way and we can compare notes

Got it. updatecdt() returns a list of dictionary. I created a custom expression

TS_UpdateFilterSettings
#filterSettings: ANY
#fieldsAndValues: ANY
=updatecdt(ri!filterSettings, ri!fieldsAndValues)[1]

This returns a single dictionary only, see the "[1]".

The code now is:

saveInto: {
a!save(
target: local!filterSettings,
value: rule!TS_UpdateFilterSettings(local!filterSettings, {the_dd_filter: save!value})
)
}

A CDT to store the data would look like
uuid: text
user: text
settings: text (with annotation to store more than 255 chars)

@mschmitt: We have a similar use case in which we want to open the hyperlink in new tab / window by default (instead of making the user to do it manually) .. a!safeLink and urlForRecord() combination served this purpose partially but the problem is we want to direct to a custom dashboard other than summary dashboard .. but neither safelink nor urlforrecord has a placeholder to define the destination record type's dashboard .. This is a must feature for us since we are providing these hyperlinks in task forms and everytime user clicks it, they are warned that data will be lost (as the link is opened in same page)

Not sure if appian handled it in newer version. We are in 7.9 ..

Below is the reference post for this issue .. Appreciate if anyone can help on this ..

https://forum.appian.com/suite/tempo/#!/news/entry/e-184773

@kumaraveln: My suggestion, which I haven't tested exactly but have looked into in the past, would be to form a custom expression rule where you pass in your record identifier and it returns your record URL for that record type. This would allow you to then turn around and perhaps append the Custom Dashboard URL stub (copied from the page URL when you're actually viewing that dashboard, etc), and perhaps link the user directly to that dashboard. It's probably to keep this pretty modular so that if this implementation ever changes in the future, it can be updated in one place (instead of chasing down 10 different task forms where it's been hardcoded, etc).

Try this and let me know if it works; if you need further help just reply and I can try to whip up a code sample and/or see whether this technique will even work as I'm predicting.

Thanks mschmitt. I already tried this approach suggested by other people and it worked .. also I made the rule common & reusable as u suggested so that modifications will be easy in future .. Same is updated in below post ..

forum.appian.com/.../

Thanks for the update - my fault for not checking out your linked thread prior to replying i guess ;-)

I would say my fault for not updating it back here :) May be I got excited once it worked after trying several options :) Appreciate your response ..

I am working on a nice solution for saving filter settings. I had to use a few tricks, but it works and is super easy to implement. It can save values from any kind of form elements. See attached file. It uses two plugins, Start Process Writer and CDT Manipulation.

Do we want to allow a user to be able to save different sets of filter settings by name? Or just a single default filter set? What do you think? I can add it, but it needs some additional form components and it might be a bit overhelming for the user.

I will post an application bundle including all necessary bits and pieces in the next days.

Save FIlter Settings Example.txt