Copy data from Table A to Table B, creating rows in the process, then delete data from Table A

[Jeff_Hager]

@MJolley

if there was a way to make an “upload student data” function where someone could import all of the data in step 1 through the app itself instead of through the Table backend

Only real solution I know of:

Allow User to Upload and Import CSV Files Tutorial

Hey fellow Gliders! Allowing users to import CSV data is a feature not natively supported in Glide, but it can be achieved through clever workarounds. The video breaks down two primary methods for handling bulk data: Method 1: Looping Workflow (for Smaller Imports) This approach involves creating a workflow that iterates through each row of a CSV file and adds it as a new record. Pros: Relatively straightforward to set up within Glide. Cons…

Deleting access rows through a relation wouldn’t use any updates with glide data sources. It’s a direct delete action without the need to loop.

@MJolley

another that pulls in the value from “Allow Students to Access App” based on whether or not they are a “Staff” or a “Student.” This is how I use a single toggle switch in the app to state whether or not each specific user should have access. But I don’t have a good way to then turn that into a workflow and revoke access yet.

If you want to use the toggle, I would still replace it with a button or custom AI component that just adds or removes the access row. But I don’t think you need that. When importing students, I would also import into the access table. When you are ready to remove access for the students, whether you rely on a toggle Boolean or not, use a relation or query to the access table to get only the students you want to delete and just delete through the relation/query. Delete can delete multiple browser through a relation without complex looping workflows.

Adding rows to the user and access table should be the only hard part. Removing rows from the access table is super easy as long as it has enough information in it to build your relation or query.

[MJolley]

When you are ready to remove access for the students, whether you rely on a toggle Boolean or not, use a relation or query to the access table to get only the students you want to delete and just delete through the relation/query. Delete can delete multiple browser through a relation without complex looping workflows.

How do I do this?

Also, now I’m running into a new issue. My app will have some functions that are public for anyone to see as well as portions that only signed-in people can see. If I use the “Access List” table instead of the “Users” table, then Glide is forcing this to be a private app which means the public can’t see it at all.

[Jeff_Hager]

@MJolley

How do I do this?

Create a relation or query column that gets the student rows in the access table that you want to delete. Could be in the user table or the source take off the screen where you want the delete button. Then add a button with a delete action and point it to the relation or query column. That’s it. When you click delete, it will delete all rows through the relation/query.

@MJolley

If I use the “Access List” table instead of the “Users” table, then Glide is forcing this to be a private app

I can reproduce this behavior. Feels like a bug to me. Maybe worth reporting. I guess my only thought would be to have a duplicate app for public viewing.

[nathanaelb]

@MJolley

If I use the “Access List” table instead of the “Users” table, then Glide is forcing this to be a private app which means the public can’t see it at all.

This is unfortunate.

You could revert to an idea that was previously mentioned: instead of restricting access using the “Access Authorisation” table, you could restrict visibility.

With the boolean value in a “Has Access” column, you could hide all important tabs of the app when “Has Access is not true”, and you could show one tab with a message saying they need to contact the administrator of the app with an email or a form “Has access not true”.

[MJolley]

I’m just trying to understand your suggestion more.

”Users” has 1200 rows (1000 students and 200 staff). “Access List” has 1200 rows as well but it’s just the e-mails (copy/pasted or imported manually through the backend) and a lookup column to determine if the row is a Student or Staff.

You’re saying that I can set up a query column in a Table (whether “Users” or something else) to “find all rows in ‘Access List’ that are Student,” make a “Delete Rows” action point to that column, and it will direct Glide to delete all of the rows in “Access List” that are Student? I had no idea that was an option, thanks!

I would like to avoid making multiple apps because there are some functions that I would need in all of them, so updating in one app means updating in the other app which could leave to version mismatch issues and be painful.

So here’s an idea: a column that queries all rows in “Users” that are Student, then an action to only delete the e-mails from those columns. This way, the data is archived, I am able to do this in just 1 Table (meaning I don’t have to use 2x the number of rows just to manage access), and I can even create a text column that copies the e-mail address over but doesn’t store it as an “E-mail” in order to keep records in case there are issues in the future. Would that work?

[MJolley]

Thanks for the suggestion. None of the information being stored for users is personal beyond their e-mail address and some staff members’ phone numbers, but I’d like to still figure out a way to hide all of that information so that the risk of the data being transmitted to every user (staff or student) doesn’t include that stuff. The Visibility setting will keep most people from noticing it’s even there, but someone who gets curious or a hacker could probably find the information pretty easily.

For most of the functions, this isn’t a concern. It’s really just for some profile information that we want to control/limit viewing.

[nathanaelb]

@MJolley

I’m just trying to understand your suggestion more.

”Users” has 1200 rows (1000 students and 200 staff). “Access List” has 1200 rows as well but it’s just the e-mails (copy/pasted or imported manually through the backend) and a lookup column to determine if the row is a Student or Staff.

My apologies, my previous response didn’t mention I would switch from a 2-table solution (Users + Access) to a 1-table solution (Users) with a boolean column for access.

You’ve mentioned this second option a few times (I think) but I feel the idea of a second table was put forward because it truly addressed access (which the boolean column does not) and it was easy to implement.

[nathanaelb]

I suppose that because of the voting and various activities, you are doing rollups in the users table so you cannot apply row ownership?

It’s a shame that setting access to that separate table is buggy, because that was such a simple and elegant solution. I think you could submit a bug report.

[Jeff_Hager]

@MJolley

You’re saying that I can set up a query column in a Table (whether “Users” or something else) to “find all rows in ‘Access List’ that are Student,” make a “Delete Rows” action point to that column, and it will direct Glide to delete all of the rows in “Access List” that are Student?

Yes, I’m saying exactly that. Deleting multiple rows is really easy. Adding or updated multiple rows is where it gets more complicated.

@MJolley

So here’s an idea: a column that queries all rows in “Users” that are Student, then an action to only delete the e-mails from those columns. This way, the data is archived, I am able to do this in just 1 Table (meaning I don’t have to use 2x the number of rows just to manage access), and I can even create a text column that copies the e-mail address over but doesn’t store it as an “E-mail” in order to keep records in case there are issues in the future. Would that work?

Yeah, that can be done, but it’s going to take server side workflows with loops or API actions, and probably updates to accomplish.