This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
These tips and tricks could be reused in various places and purposes within Appsheet by twisting a trick a bit. Currently, we are not able to temporarily hold so-called “variable” value, which is adhere to the particular log-in user only.
This has been discussed and solved the problem in the post where you can find the originals through the link below.
On this trick, we capture any “variable” you can to capture and temporarily store within App as physical data (clearing cache from browser wont affect) and use those variable to pass to the actions and workflow.
This is similar concept in terms of holding user tables to store the data attached to each log in user, but slighly different as well.
In the original post, App want to capture the value of “Enum list” by users choice. And store the a enum values as variable and then pass the same to workflow/actions.
thank you very much @tsuji_koichi, surely the solution is genenial, but unfortunately I can’t see under the hood. Apparently in order to see your example, I have to make a payment. Is it really this way?
Again thank you very much…
Is this Tips & Tricks post from you solving that issue? Perhaps it was taken down due to AppSheet fear that it would allow devs to create their own user identification system (albeit not securely)?
Hi @Ed_Cottrell
I just read your feature request, and I understand from where your request and frustration are coming from.
The technique I shared in this old post is just the same as you are explaining. Just utilize the user table to store the user-based variable, but to make it works, we need to wait for sync to be completed to work perfectly, especially the value of variable is used for vc or action, othewise the app will pick up old variable which is causing problems.
Yes, we still need to wait for new feature to come to hold the user-specfic variables on user device (clients) and the access to those value is immidately available after we change the values.
What I m dreaming now is to get the additional functionalities to INPUT() expression. According to @praveen , INPUT() expresion functionalities will be expanded as the time goes by. It will possibly include the capabiiteis that we change the usersettings value through the action. Once this is coming through, it could be possible that we alter currently tequnique of User table, but just simply use usersettings value as variable to manipulate bits and pieces.
Hey @tsuji_koichi - I agree it seems we just have to wait patiently.
Re using the input() function to set a variable in the device user table (maybe in future) this is helpful, but even a step before that which would add huge improvement is just to have the device user table available to create views on. That’s it. It really is all that is needed. Ability to create a view (or multiple views) on the device user table is all we need. Oh, AND ability to add more columns (variables) to the device user table, so it’s not limited.
@praveen are we dreaming here, or can you shed some light on if this simple request (ability to create views on the device user table) is something that might/could be looked at in the future / when / if at all? As it stands, we have literally 1000’s of users that are waiting for us to deploy a multi-tenant (business) offering to, but really I’m not wanting to deploy and kill all the good work we’ve done in pre-selling by serving up a product that simple doesn’t work well enough. We will loose those new users as quickly as we bring them on.
LinkedIn
Twitter
