User Attributes, essentially user groups

[Mordan74]

It would be great to be able to set attributes against users, either a text field, EnumList field or Enum field.
The purpose of this is to be able to assign users to groups.
In my example I have dashboards that I want some users to be able to see and not others depending upon what department they are in.
In this example I have 3 users.
We have a field called USERATTRIBUTE1 that we can set as an ENUM and I have a number of options; ITS, CIVIL, ROAD LIGHTING, ITS/CIVIL, ITS/ROAD LIGHTING, ALL, CIVIL/ROAD LIGHTING
It would be good to be able to use the showif function of a view to set showif or([USERATTRIBUTE1]=“ITS”,[USERATTRIBUTE1]=“ITS/CIVIL”,[USERATTRIBUTE1]=“ITS/ROAD LIGHTING”,[USERATTRIBUTE1]=“ALL”) or any of the others so that I can essentially set access to views.
It is painful to have to use USERNAME() as that can be inconsistent depending upon the authenticor as well as having to add new users in to many different places.
This way we can create all the combinations we need and have complete control in a very simple way.

[WillowMobileSys]

Are you aware of the USERSETTINGS table? Maybe this will work for your needs?

[Austin · Accepted solution]

Sounds like a user table would suit your needs.

[Lucinda_Mason]

This got me thinking about the best use of user settings table vs a Users table in your data source.

I see a major limitation, in my very limited research, of the following:

“Unlike normal tables, the user settings are stored on the device itself, not in the cloud. Consequently, user settings do not follow the user between devices.”

My users will probably go between a desktop and a mobile device. Based on the above, they could have different values in the App’s user settings table.

Plus, using a Users table in my data source allows an Admin to add new users. I don’t see how that is possible in the app’s user settings table.

What do you use? Any good scenarios on why one is better than the other?

help.appsheet.com

User Settings: The Essentials

Give users more control to customize app behavior.

help.appsheet.com

User Settings: Appropriate Use and Limitations

When and why to use user settings.

[Mordan74]

I haven’t had a chance to do any testing as yet but I am certain that USERSETTINGS won’t work for me since I can’t rely on the user choosing the data they need to see. In this case I don’t want the user to see the views they shouldn’t.
The UsER table seems like the way to go however I am unsure about the syntax to use in the showif setting of the view but I will figure it out quickly if it’s possible, which I’m sure it is.

One thing that I am doing is applying an admin pin in user settings that allows editing, show fields and views etc that only an admin should be able to see/perform. That works really well and allows changes within the app that would sometimes cause a duplicate
spreadsheet in OneDrive due to admin manipulation at the same time as user edits in the field. This also allows me to enable fields for manual entry to override update actions.

I guess I figured that ENUM fields against users would stop having to double up creating a user for access as well as adding them to a user field but the user table will work I’m sure.

[Steve]

Mordan74:

The UsER table seems like the way to go however I am unsure about the syntax to use in the showif setting of the view but I will figure it out quickly if it’s possible, which I’m sure it is.

The idea would be to have a table or slice with only the single row of the current user. Then you can access a column’s value using ANY(): ANY(UserTable[Email]). So long as you ensure UserTable contains only the row of the current user, this is a good way to access the user’s values. For Show If, you might have something like ("Admin" = ANY(UserTable[AccessLevel]) to show the column if the user’ has admin-level access.

[Lucinda_Mason]

Steve, I’m still very new to AppSheet but I don’t see how this would work in an app with many concurrent users. Would’t additional users simply over-write the info from the most current, last, user who is probably still using the app?

[Steve]

Suppose you have a table named UserTable, with at least a column named Email that identifies each user;s email address. Your app could have a security filter with a filter expression of (USEREMAIL() = [Email]) to filter out all but the current user’s row. The downside with this approach is that the rows for other users won’t be available to the app should you need them, but it’s very good for security. You’d have to manage the UserTable (add and remove users, e.g.) by other means.

If you need the app to have visibility of the entire UserTable, you could not use a security filter and instead use a slice (called CurrentUser, e.g.) atop UserTable, using the same filter expression given above.

[Austin]

So a very good rule of thumb to follow is if you are ever going to update a value it should not be in the user settings table. I have been using the user settings page to hold my user’s ID and permission level via formulas within my app and it has been working perfectly until the moment I tried to update a user’s settings. The settings table cannot be forced to update without the user going in and hitting save.
The user settings table should be used for things like inner filtering, like how old do I want my task list to show me, what color do I want for format rules, etc. Using the lookup/select from the User table is slightly uglier for coding but I think if I could go back I would just use the Lookups(I don’t know the performance implications of using User table vs Settings but I believe Settings is MUCH faster because I have an over abundance of uses of my values from the Settings table and I have been told that the settings table is closer to calling a variable than querying a table).

[WillowMobileSys]

@Lucinda_Mason @Steve @Mordan74

I initially suggested USERSETTINGS becasue I thought we could set Show? to “off” and then from the app control/reset the settings. But based on this comment…

Austin_Lambeth:

it has been working perfectly until the moment I tried to update a user’s settings. The settings table cannot be forced to update without the user going in and hitting save.

…I am gathering that once the initial value is saved onto the device it cannot be updated from the app without user intervention? That, I did not know!! So, if that is the need then a custom UserTable would be the way to go.

BY THE WAY, I have some time back, submitted a request for an APPSETTINGS table. The initial thought was for “static” type of settings we might want to use throughout the app. But, based on this discussion, I could see a use for conditional settings as well. Please check out the Feature Request, add comments and vote it up!

Provide an APPSETTINGS[] list similar to USERSETTINGS[] Feature Requests

I would like to request to add a list of settings that are user updated but apply to the application across the board to all users. This would be similar to USERSETTINGS. In fact, I would recommend changing the “User Settings” tab in the editor to simply “Settings” and then have a “_PER USER SETTINGS” list of values and then a “_PER APP SETTINGS” list of values. I do understand that the same thing can be achieved by adding a sheet with these values. But the difference is how we reference the…

[Mordan74]

This gave me enough to head in the right direction.
I created a UserTable and created columns for IsSomeRole, Yes/No. Then create something like any(select(UserTable[IsAdmin],([UserEmail]=USEREMAIL())))=Y
Obviously users have to sign in but this gives me the ability to stop editing, showing at the record level, add, edit, delete at the action level and just show at the view level.
It works perfectly.

[Steve]

Moved to #ask.