Persistent User Settings component file (OTHER THAN ASO or AppInfo)
With all the new enhancement and features of SP1, has an out of the box component been created to be used for the frequently created automation of storing persistent user settings? (NOT ASO for signon or repurposing the AppInfo file)
Also prefer not to use a lookup table component with data table or save as xml.
Looking for 1 out of the box component with multiple methods to get and set user settings to a persistent local file.
User logs in day 1 and sets a setting for role = 'Role 1'
User logs in day 2 and 'Role 1' is used in automation by checking the userSettings file.
At its core, it writes data to a user directory on disk and is retrievable "tomorrow". Other than that, there is no out of the box component to do what you are asking in as tidy of a package though. You can write a C# script to read and write a text file and you could store that in a common location or on a network share when you have users that switch between machines. You'd need to write logic to read from it, but we do include a JSONUtils object in later versions that can serialize an object to a string and deserialize that object.
I have attached a sample solution where I write the settings to a LokkupTable setup like a Key Value pair. Whenever we write a setting to it, I use the JSONUtils to serialize the DataTable and then use the static method WriteAllText to write the contents to a file. We can reverse that process whenever we start runtime to read the text file and deserialize it. It isn't as tidy, but you could write this inside a simple automation and import it as needed.
Thanks Thomas for letting me know there is not an out of the box component to do this.
Per the link you posted the CredentialsStore uses the AppInfo file and was for UserName/Password/Domain.
"The CredentialStore component lets Studio store items such as user name and password in an encrypted format for use in an automation. Studio and Runtime place this information in the AppInfo file in the following directory"
The credential store doesn't care if what you are storing are credentials. I use it all the time if I have a user-specific setting I want to store. The only caveats in its usage are that it must store a username and password, and it has length limitations (its pretty long though). It isn't possible to use this for user-settings without roaming profiles turned on, since it encrypts data with elements from the user's profile folder. If you wanted to store these settings in My Documents or on a network share for example, then it would not work (at least across machines). I was thinking about this more last night though and you could simply modify this automation to accept or return parameters to either get or set settings and then it would act like a wholly self-contained component.