"View As" NOT Viewing As


When I “View As” and look at the Screen Data for the current TAB the ‘data’ does not change to the person I am “Viewing As”.

The TAB’s source is the User table.

When I “View As” myself (Matt) the SCREEN | DATA shows my data.
When I “View As” anyone else (e.g. Jim) it shows the data for the User directly below me in the User list who is not Jim. And the reports/data is MY data and not Jim’s data.

Row Owners is set to Role and email. I have verified that the data is visible for User Jim.

The SCREEN | DATA only changes to either myself (the first row in the table) or the second row in the table.

The data I view is ONLY my data or the second row of data (which is nothing).

This does not appear to be the expected behavior for “View As”

My App/Pages Support link:
Learn how to create one: https://gl.ink/slink

Describe the bug:
Describe the bug in simple terms

Expected Behaviour:
What should happen?

How to replicate:
Describe in detail how to recreate the issue

You can create one using https://www.loom.com/

Do you have the Role column configured in your User Profile setup?

Role is configured in a google sheet. It works (I think) because when I change Users I can see (in the data editor) that Row Owners is working correctly (e.g. Matt can not see Jim’s data and vice verse).

The TAB “data” only toggles between the first and second entry in the User table (“Paul”).

But when I change from Matt to Jim in “View As” the screen data shows Paul who is the second entry in the table. Every “View As” user I select gets the Screen DATA set to ‘Paul’ versus their own TAB data.

If this is the expected behavior, it is working. But I have data associated with that row that is not showing up as expected when I “View As” another user (like a table I created based on your great feedback over the weekend! :slight_smile: )

Do I need to physically login as this user to see the data correctly in the tab DATA section?

You mentioned that you have the Role column set as a Row Owner. That’s not going to work properly unless you have the same column configured in your User Profile setup. This is why I asked the question. So when you click on “User Profile” (just under Menu in the Tab list), you should see something like this:

Note that you’ll only see the Role option above if your App is Private.

The app is not private. I found the “User Profile” tab and it switches correctly whenever I “View As” a different person (the DATA section changes correctly as I “View As” different users. The “User Profile” table is set to a google sheet called “Users”

However, in the APP I am using the same table - “Users” - as the source for each of my tabs and the DATA does not change properly when I “View As” a different user.

Net/Net": “View As” works when I am on the “User Profile” TAB but not for any other TAB.

I have to run an errand but after messing with the roles it looks like it is definitely something to do with roles. I deleted Row Owners for “Roles” and I get a completely different set of responses when I check the DATA results as I “View As” different people.


Does your screen have any filters in it, or are you completely relying on Row Owners to act as your filter? Is it possible that you are viewing as someone that has row owner authority to that second row in your user profile table, even though it’s not their own user profile row?

I removed row owners from Roles. I have 4 primary roles: Admin, User, Manager, Director

Matt is Admin, Paul and Greg are Users.

Each user has their own private data in their User Profile/Users’ row (USC data, etc)

When I go to User Profiles in the Menu area and “View As” and check the DATA it is correct.

Matt is Matt, Paul is Paul, Greg is Greg.

If I look at it on any TAB I get a different result:

Matt is correct and is the first user who is an Admin
Paul is a User (and Paul’s data is Paul) (Paul is the FIRST User in the table)
Greg is a User (and Greg’s data is Paul)
Everyone else who is a User is “Paul”
Anyone else who is an Admin is “Matt”
The first Manager is correct (in the DATA area)
The second Manager displays as Manager 1 (in the DATA area)

Their is only one Director so their data is correct but if I add another Director I expect their 'DATA" will be the first Director’s DATA.

It appears that the SCREEN DATA is NOT the User but the FIRST User with the Same ROLE as the “View As” user.

I hopes this makes sense.

Net/Net: I am NOT getting the correct User information on the TAB, I am getting the first user with the same Role as the “View As” user. And it is messing up my APP’s reporting…sigh…

Obviously I am using this system incorrectly.

This data is simple but critical roll-up report which I will now must try to figure out a different place to put the data. Putting them in the User table let me access them across TABs with the bonus of changing “Views” which was supposed to give me a simple way to test the process and validate the data.

Net/Net - my ‘assumption’ that “View As” let’s you view as a specific user is probably incorrect; it appears you are “viewing as” a ‘generic’ User with that user’s role. The ‘specific DATA’ for that ‘generic’ User is the first User of that class/role in the table. That is why Paul is the DATA for all Users, Matt is the DATA for all Admins, etc.

Am I getting warmer?

Let’s take your USER role as an example. Multiple users have the same role, and if you are using roles as row owners, then any one user with a role of USER will have row owner authority over all users that also have the same USER role. If a screen is not filtered, then it will default to the first row that is found in the data… meaning the first user with the same role. It sounds like you are just missing a filter on the screen to filter the screen where email is signed in user. The USER role will still limit downloaded data to all rows that contain USER, but the filter will limit the screen to the user that is signed in.

Pardon my french but fuque!!!

I added a filter as you recommended and all looks correct. Jim is Jim, Dominque is Dominique…etc.

Sigh…very time you add a filter you get a security warning which has made me VERY wary about any client-side filtering.

Just venting about another wasted 3-4 hours learning “Glide nuances”.

1 Like

Hehe, yeah 90% people are using row owners with a single email only, so it’s pretty much the same as using a filter, but once you have multiple owners of a row, then you need to consider using filters as well.

Row Owners control which rows of data are downloaded to a device in the first place. That’s why they are more secure.

Filters control which rows of data are visible from the data that has been downloaded. (Thus the security warning. Filters don’t protect data. They only control visibility of it.)

1 Like

I still don’t understand why “Paul” - who was not a row-owner within the Users table - was being downloaded in the first place and had to be filtered to keep from ‘showing up’ in the data. I looked at the table and his ‘row’ is greyed out. Shouldn’t that mean the client-side should not download it?

That is why I did need consider filtering him in the TAB screen. It worked but it doesn’t seem consistent.

@david @Mark - This seems like a security concern

Paul and Greg had a role of USER. Meaning if the role column is set up as a Row Owner column, then they will have access to all users with a role of USER. Am I misunderstanding how you had it set up?

Not in front of system but Matt is an Admin and Paul, Greg and Jim are USERS.

Jim is the row-owner/USER I was testing via “View As”. row-owners is an OR so if I had row-owners set on email AND set on role than anyone who is also a USER would have access to the data?

But if I only had email as row-owner than only the actual email address (Jim) would have access?

The devil is in the details.

It’s an OR in the sense that a user has to match in one row owner column OR match in a different row owner column. So yes, if the role column is also set as a row owner column, then the role that is set for any particular user will also allow them access to any other user row that has the same role as themselves.

Yes that is correct.

This gets a little hairy though. I think you are trying to dual purpose the role column. Especially since you are trying to do it with the user table. It would make more sense with any table other than the user table, because you would just be setting a role in those other tables as the row owner as needed. You’re also pigeonholing the admin, since they don’t have a role of USER, then that means the admin won’t have access to any users except themself.

I think what you should do is set the role column without row owners, but keep it set as the user profile role column. Then create another column (maybe name it ‘permission’), put Admin in every row, then set row owners on that column. That will give the admin access to all user data, but all other users will only have access to their own data because they don’t have the role of admin. The email column will be the only row owner column kicking in for the users as the permission column won’t find a match for row ownership…accept for the admin.

1 Like

Is it a security issue or a training issue/development environment issue? Best practices for security issues should be a must have. The tools around viewing APP data especially with a focus on security is a HUGE differentiator. My target customer is GLIDE once they focus on corporate America and I am more than a bit concerned about what data is coming to the app knowing how valuable it is. I don’t think about it with Salesforce even though it could be less secure. But I do with Glide.

I think Glide needs a MUCH stronger focus on security especially as you are focused on unleashing all that data stored In corporate spreadsheets and making it actionable and accessible to many more people than someone’s local drive.

If it helps, I’d suggest studying this documentation to learn how to properly secure data.

Best practices like this would be a big benefit! I think my vision of the APP and what Glide was initially built for are somewhat divergent.

At least it is two steps forward for every half step backwards. But those half steps are always very surprising because they occur when you least expect them!

This is not really a white paper and I read it discussing what you should be think about which I thought I was following. But details get in the way such as how should you handle “global variables” used in select/choice components and lots of other features.

I started with a “home” table with much of this info in it. Heading back that way. But the issues is that Users is special and it seems it can be accessed in a lot of places. So dumping data there is natural.

Not being a developer by trade but an SME in my field, Glide looked like the ideal tool. But it is not straightforward. The saving grace is the community and people like yourself.

I think the problem is that there are a million ways to skin a cat, a million ways to design a database, and a million ways to design an app…and people will try them all regardless if it’s a best practice or not. Trying to address each and every possible scenario, and each best practice for all of those scenarios, can be difficult. Glide has added warnings here and there, such as on filters to indicate that filters alone are not secure. I also think they are planning to focus on simplification. I’m sure they would take other suggestions for warnings and other ideas as well.

Your case above could be considered unique to some level. Like I said, you are trying to dual purpose the role column. You are assigning the role column to the role setting in the user profile settings, which tells the app to grant access to the data if a user’s role matches the value in a column that is assigned as a row owner column. This setting will then allow glide to look at which role was assigned to the signed in user. Any row of data in a table that has a row owner column that contains a matching email or role value for the user that is signed in will grant that user access to that row. In your case, you also assigned that same user profile role column in the user table as a row owner column. So, it’s taking the role for the signed in user, and looking for any rows of data that have row owners applied and where that column contains the same value as the role of the signed in user. Thus the admin can only see rows that have admin as the row owner, and users can only see rows that have user as the row owner.

I do try to stress security as much as I can and I have seen some very questionable methods used in the forum. I will also admit that I have snooped data in these questionable apps and notified the owner if I feel they are not following best practices. I have no I’ll intent, but I want to make sure data isn’t being leaked somewhere due to a poorly laid out app.

If someone is working with sensitive data, I think it’s imperative to have a solid understanding of Glide’s core functionality before unleashing an app. If there are ever any doubts, it doesn’t hurt to just ask, or hire an expert to do a security audit. I think the experts have a very good understanding of how glide works and how to properly secure data.

I’ve been a developer for over 20 years, so yes I’m biased and my mind does think like a developer. To me glide is pretty straight forward out of the box, but many people, myself included, will try to push the boundaries of what glide is capable of doing instead of staying within it’s confines. It’s lead to a lot of feature creep over the years, which for many of us has been awesome and beneficial, but can be daunting to new users. It’s also lead to a lot of new users wanting to do things that require outside third parties, such as Zapier, Make, API’s, javascript, scripting, etc., or people trying to use CSS to hack their way around glide functionality. I think glide is trying to cater to many of the user’s needs, which also adds to the complexity. At what point do you sacrifice ease of use, while maintaining expansive functionality and flexibility? I think at some point you would have to take away features to keep things simple and understandable, but you also have to realize that this is a no-code development tool and it won’t have all of the features of full code development.

Overall, I think glide has a basic set of “rules”. It may take a bit to fully understand them all, but once you do, it’s pretty easy to build upon them and create some pretty wild functionality.

I always approach a problem by starting with the result I want. Then I think about what I need to get that result, and I keep working backwards until I get to the beginning, and at that point, I have my solution. Trying to start from the beginning first can lead to confusion sometimes. Let’s take your example for instance. You know that you want a User role to only have access to their own data, and that an Admin role should have access to everybody’s data. You know that assigning an email column as a row owner will grant a user, with that same email, access to their own row. You know that a user with an assigned role should have access to any rows with with a row owner column that contains their same role. You also know that you have assigned each user a role in the user profile settings by pointing it to that role column. You know the “rules” for how row owners work. Knowing that much, you know that a user has access to their own row at this point. All that’s left is to decide how you are going to indicate that an admin can access every row, while a user can still only access their own row? You have two ways to do it. First you create a new permission column and then you have to decide to either place the admin’s email on every single row in the table (which is not very scalable if you have multiple admins), or you place the admin role value in every single row in that table. Then you apply row owners to that new permission column. So in the end you now have two row owner columns. An email column with the email of each specific user in each row, and a permission column that contains the admin email or admin role. These are separate from the role column which is used in the user profile settings, and to match up with any column marked as a row owner column. When a User signs in, only the email colomn will match the email they signed in with. Their role won’t serve a purpose because there will be no row owner column that will contain a value of USER. When an Admin signs in, the email column will match, but also the new permission column with ADMIN will also match. Their own specific row will match in two cases (once for the email row owner column and once for the permission row owner column), but there will also be a single match for the admin on all other rows, because their role of ADMIN matches the new permission column which also contains ADMIN on every row.

I think you will be fine as long as you have a Role column (without row owners), which determines the role of the user in that row, and a separate Permission column (with row owner applied), which determines which user roles have access to that row of data.

As far as global variable using the user profile row, just remember, that accessing that global user profile (through a drop-down) will always always always refer to the signed in user’s row.