Re: Adding User/Company Specific Staff to List

marsbar · 12-13-2024 11:04 AM

Hi All

I have a Staff Access list I use that shows certain users ONLY their relevant company or access level information... I now want "Superusers" to be able to Add new members to the list, but only to THEIR company

So Im wanting to achieve:

I only want Super Users to be able to add staff, and only to their company... eg. User 1 (A Super User) to be able to add a user to Company A only

I only want Super Users to be able to see staff from their company... eg. User 4 (A Super User) to be able to see staff from Company B only

This is an example of the table -

Please can someone help - I would like the users to be identified by UserEmail() if possible (so UserEmail = Email in the table.

Thanks In advance!!

WillowMobileSys

First, I strongly recommend to implement the "CurrentUser" slice as outlined in this post - Current User (Slice) | How to conform your app around WHO is using the app

It will make implementation around user abilities and permissions much much simpler. No matter what you do, I would include this implementation in every app!!

If it is true that you want SuperUser's to only ever be able to insert and view staff for their company and have no access to any other features, then I would handle this by creating a separate app that does ONLY that and give access to that app only to SuperUsers. Not only does this help keep implementations clean in the respective apps but it also ensures these SuperUser's can't accidentally access other feature unintentionally. This is the quickest and easiest solution

If you do still want to fold this feature into your existing app, the best way to handle it then is to use Security Filters (Security Filters: The Essentials). The idea is, If the CurrentUser has an [Access Level] = "Super", then don't allow data for any table to be downloaded EXCEPT the Users table. You will also need to hide any Main and Menu views that "Super" should not have access to.

I hope this helps!

marsbar

Hi, thanks for this.

I do use this table and a Current User Slice of it in my apps. It really does work great - so Im glad its something I'm doing right!

What Im after though is a way of letting Superusers within that certain company add staff to the list so that they can then be part of the security filter. So this is the overarching App Security filter table - but I want superusers (of only that company) to see and add users (to that company only).

Ive tried using another table that references each of the columns from the above table, called This User, eg. in the Company column of This User Ive used "current user[Company]" to pull through this current users info.

Then in the original Staff Access Table settings Ive used

"IF(CONTAINS(This User Slice[Company],[Company]),TRUE,FALSE)" basically trying to look up whether the current users company is in the above table, then show only those rows (and allow them to only add rows with that company).

Does this make sense?

So this is my Security Access table used throughout my apps, but I want superusers ONLY to be able to view and add to their company staff ONLY.

Thanks again and please let me know your thoughts.

Cheers

WillowMobileSys

Hmm, maybe what you are struggling with is being able to look up the user for the CurrentUser slice, get the Company details and then be able to further filter the users to only those this Superuser can access.

It's kind of a "chicken and egg" problem. The best way I have found for this situation is to allow the full user table to be loaded and then create a Slice, maybe "Company Users" that reduces the list of users to be used in the app and use ONLY this slice to get User data in the app. the expression you would use in this Slice would be:

[Company] = ANY(CurrentUser[Company])

If the users always have email domain names that are associated with the company - e.g. user@company.com - then you could use the Company domain name from the USEREMAIL() function to filter the users table directly - no Slice needed.

I would still advocate a separate app for the Superusers since this seems to be the only function those users will ever be performing in the app. this app would only bring in the table needed to perform the necessary User adds and maintenance. The app will still need the "Company Users" slice noted above.

FYI: if you have an Enterprise Plan, you might look at using Partitions to segregate company data.

MultiTech

@marsbar wrote:

What Im after though is a way of letting Superusers within that certain company add staff to the list so that they can then be part of the security filter. So this is the overarching App Security filter table - but I want superusers (of only that company) to see and add users (to that company only).

Since you've got the current user system going, and you're already using roles, what is the issue with letting super-users create other super-users?

Isn't this just a matter of the super-user granting that role to others?

Valid-if Formula for User_Role column:

if(Index(Current_User[User_Role], 1) = "Super-User", 
  list("Super-User", "Admin", "User"), 
list("Admin", "User")
)

----------------------------------------------------------------------------------------------------------

As long as you've got the app data filtered (at the security filter level) based on the company that a user is assigned to (like, a physical column in the user record that holds the ID of the company(s) they belong to), you won't have the issue of one company seeing another's data.

-----------------------------------------------------------------------------------------------------------

If you need a user type that see's everything, disregarding security filters, so that person can see everything and debug and what not - create a "Dev" role.

@WillowMobileSys wrote:

The best way I have found for this situation is to allow the full user table to be loaded and then create a Slice, maybe "Company Users" that reduces the list of users to be used in the app and use ONLY this slice to get User data in the app

Agreed.

Hope it helps!