I’ve had an issue completely stumping me for a week in my scheduling app. Users book hours whereas their data is first in a table with many USC that have several Mth and ITE columns reading from them for app features. When the User submits their hours, the USC data gets set in a new row in another table of basic columns. The Admin goes in to the second table to make any necessary adjustments and then approve the hours. However, I couldn’t think of a way to send the changes back to the first table of USC as I need the new data to go to the Mth and ITE columns. But the Admin can’t touch the USC of the Users via the app interface if the data is only on the User’s device, (and in the GDE but tied to the User’s email).
It got me thinking, is a USC really as I believe it to be - not accessible via the app interface from any other device other than where it was entered? So I loaded my app onto another device, signed-in with the same email as the original device, and tried some USC things. Well, Glide made the changes on both devices and in the GDE nearly simultaneously, and my mind was blown. So the data is tied to the User’s profile, but not the device. (It’s not called user-device specific column, duh…)
So now my question is; through the app interface can an Admin “view as XXXXX” a User’s information, including the USC items? I can’t figure out how it could be done. The info can be pulled from the Glide Tables, but how? (As the Admin)
This is where I think you’re possibly making a mistake.
Once the user submits their hours, and the new basic row is written, then that row should be the authoritative source of that data. If the user needs to subsequently view and/or edit the data, then they should be viewing this row of data - not the values in the user specific column that were used when they submitted the data.
Maybe I need to understand more about your use case, but my gut feeling is that you’re trying to use User Specific columns for something they’re not intended to be used for.
The first table has the required hours set by the Admin in basic columns, I probably should have mentioned that part. When the User adds their hours in the USC, and then sets them, I’m incrementing another set of basic columns that is being compared to the Admin required hours. As the Users book hours, the components on the interface start to be hidden when the required hours are met. This worked great… until modifying hours was required. Because if the Admin removes some hours from a User’s shift in the second table, I need those hours to be added back in the first table so that the components can be visible to other Users again. And it’s not so simple because I need to know the exact day & hours to send back and match up. I would just swap out the entire shift for that User and undo/redo the incrementing, but I have to grab that shift info in the first table and at this point I can’t.
In the GDE I can modify the USC of any User, but now I’m greedy and want that functionality in the app interface.
Lets call the table where the user enters their data Table A
And the table where the new row gets added Table B
Tell me if this makes sense:
When a user is viewing previously entered data, they are viewing a row in table B
If a user is allowed to edit that data, then you have the following:
A single relation that links Table B back to Table A (via the User ID)
An edit button on the details view for rows in Table B. When the user taps that button,
Via the single relation, do a Set Column Values on all your User Specific columns in Table A, using the basic column values from Table B
Then do a Show New Screen → Table A, and expose all the User Specific columns and allow them to be edited.
When a user is done editing, take the User Specific column values in Table A, and use them to update the Basic Column values in Table B via another single relation.
You can do that, and it’s exactly how a custom edit screen works. With a custom edit screen, the flow is as follows:
User is viewing a details screen of a row
User taps (custom) Edit button
Set Column Values action writes all applicable basic column values to user specific columns
User is presented with screen with input components that are reading from user specific columns, and writing to the same columns
When user is done editing, they tap a (custom) save button, and a second Set Column Values action takes the values of the user specific columns and updates the associated basic column values.
What I suggested above is a variation on this flow.
Just a sidebar to help explain User Specific Columns. User Specific columns will be device specific and only store temporarily while the app is open, ONLY if the user is NOT signed in. If a user is not signed in, then the user specific columns are only temporary. If a user IS signed in, then those user specific column values become attached to that user, regardless of device.
How I believe they work, is that glide creates a hidden table that’s attached to a normal table. This is why RowID’s are required for user specific columns to work. I believe behind the scenes they create a joined value with the user email and the row ID joined together in some way. Then they create a relation from the normal table to the hidden table where all of the user specific values are stored. I think it’s a simple relation/lookup combination that glide handles automatically when user specific columns are added. That’s why it can store values and show them across multiple devices for a specific user when they are signed in. If a user is not signed in, then glide has no way to differentiate which user specific value belongs to which user, so in that case a user specific column value can only become a value that is stored locally and temporarily on a specific device.
While you can impersonate any user within the builder, accessing user specific values for another user from within the published app is not possible. I believe…like row owners…only the user specific values for a signed in user are downloaded to a user device, so there is no way to access user specific data of other users.
