Our users table is protected by row owners, and the staff has row owner access to all users (4K rows).
The pages the staff see in the app is based on visibility settings based on their Role. This helps show them relevant functions for what they do.
Without Row Owners, the visibility settings work immediately, but with row owners they take a very long time to work. My theory is that the app is first downloading all of the user data, and then figuring out the role the staff member has. As opposed to figuring out the logged in users role first, and then moving on to download the data. We need row owner since it has all important client information. Is there a way to make visibility settings work instantaneously, or a better way to go about doing this?
Consider adding filters to the collection and adjusting limit and pagination for the displayed data. Remember, filters and visibility conditions are not security features; always use row owner to restrict data access, assigning user email and role as row owner if needed. Simply set a column as row owner with the permitted role.
We have everything protected with row owners based on the staff role. The issue is that the userās table is taking too long to determine the role of the logged in user.
So the staff is working with a separate āordersā table that they have row owner for the specific case they are assigned to (so in a way itās already filtered). But since the page visibility is based on the userās table role itās taking a while for it to show them the page itself. Itās probably downloading all 4,000 users first, and then deciding what they logged in userās role is. I canāt use filters since the filter only works for the specific collection āOrders tableā but the issue is with the User Profile table that determines the visibility.
I already have row owners set up in the profile table, thatās the issue. Without row owners in the profile table the visibility settings work immediately. With row owners, the visibility settings take a really long time to determine what the logged in users role is.
The users table has 3 row owners. (1) The actual user, (2) Admin Role (3) Staff Role. Admin and Staff have access to all users. The pages that they have access to have a visibility setting to only show that page to āAdminā or āStaffā, and the app is taking extremely long to determine that logged in user is an Admin/Staff.
You might want to add a loading component when the data isnāt loaded yet (not found yet). What type of columns do you have in your user profiles table except the 4 default ones ?
Row ID, Address (7 cols), Phone, Language Preference, Relations to all other tables, Row Owner role access.
The loading component would be my plan B, but wanted to see if thereās anything I could do to not have to do that. If the logged in users data is downloaded before anything else, it would solve this problem.
My other solution was to create a new users table that would just have the log-in info and keep the current table with the users information for internal use only. That way the public table can be kept with just the bare bones information and can be purged often, and with only the logged in person as a row owner. It would require more adjustment since the app already runs a certain way, but thatās all I can think
Yeah. If it needs to download everything before reading the logged in userās profile, itās going to take a while considering itās 4,490 users. I think the only way is to have a table just for log ins that only gives row owner to the specific user without any staff access, and then keeping the current users table for practical use.
I donāt believe it downloads rows first, that defeats the purpose of row owners/roles. They prevent rows to be downloaded unless you have access to them.
I would suggest you using the performance mode to see which columns are taking the most time to be calculated.
I wouldnāt mind betting that itās the 9 relation columns that are the culprits. I believe that in order to build those relations, itās going to load the data from all 9 tables. And if it then has to calculate those relations for 4.5k rows in your users tableā¦
But yes, run a performance analysis as @ThinhDinh suggested. That should tell you.
I donāt think the problem comes from relations and computed columns since these one are loading in the front end. @bman737 seems to say that the slow loading happens when he enables row owners. That means that Glideās backend is filtering the data before sending it to the user. Because there is a lot of data and multiple row owner columns, tha tis probably why it is loading slowly and taking more time to retrieve the data.
I ran the performance check and itās showing the maximum time for computed columns is 29.5 ms for the current Users table.
This issue only happens when thereās row owners. Thereās 4.5 rows in the Users table, and itās linked to several other tables that also have row owners. (Those tables have 4-5K entries as well).
If Glide would process the specific logged in users record before moving on to everything else it would solve the visibility issues. But it appears that itās having to calculate everything first, which will always cause a delay with that amount of data.
My current solution is to create a new users table with just bare bones information (as a log-in table) with only the logged in user as the row owner. This will hopefully load the logged in userās email/role quickly and they can at least see the components relevant to them, even as the other table data is being downloaded. Weāre at 17K total rows in the app so weāre reaching the limits of Glide and will soon need to move to another solution. I can still archive things to keep us going but itās going to be a problem eventually.
Throughout the entire a year a little over 3,600 (around 300 per month). The other entries are just potential/older clients. These clients only use the app once or twice when they have an order. The staff which is around 8-9 use it regularly and they need access to more records.
Would archiving data from the main user table be a viable solution to optimize its performance?
You could create an archive table to copy the old user to it and then delete it from the main table.
