I now need to essentially transpose that data so that it is also in columns by status or can be displayed as if it is. I essentially want to do two things.
I want to be able to display that data in a list where the list or lists are grouped by status, I.e.:
Review
Doc 1 - Client A
Doc 2 - Client B, Client C
Approved
Doc 3 - Client A
Doc 2 - Client D
In a list of all documents, I want to include the name of the client and their status, sort of like this.
Is there a way to do both by essentially transposing the data in the data editor or using a template? Or some filter trick in the collection I havenāt thought of?
Iāve seen @Robert_Petittoās Miracle Method, but that seems like more than I need hereā¦
Having each Client as its own column raises a red flag for me. I think instead, youād want the statuses as column headers and a comma-separated list of clients for each document & status.
What are some of the red flags? Iāve already begun implementing it with each client having its own column, but not too late I suppose to change course.
But also, if I do as you suggest, how might I achieve the display in my second example?
As @Robert_Petitto said, it is a bad idea to make separate columns for each client, add 3 status columns, and place clientsā IDs thereā¦ so instead of Client A, Client Bā¦ create Review, Draft, and Approved columns.
This way, you can have dynamic Docs and Clients.
Then create an inline list that will get relations to usersā IDsā¦ so you can generate Clientsā statuses for each document, In the detail view.
But if your Client list is fixed, then it is ok to do your method.
Itās a red flag because user data and identifiers donāt belong in column headers. Glide canāt use data within column headers to make relations or create filtering and conditions.
Instead, I would do as I suggested above and then do the following:
Thank you both. And particularly @Robert_Petitto for the very clear video. Wow!
I suppose I should have made one thing clearer. āClientsā in this instance are just an organizationā¦(e.g. āThe Coalition on Good Ideas.ā )they arenāt users in the user table. I can see the alarm if I was going to put user names or other data that relates back to the user table as a heading. Also, not sure if it matters, but setting the status (review, draft, etc). is something that is done by an admin user.
In any event, I think Iām convinced that making the status the column header is probably better. But I have some followup questions based on what youāve presented. First, a quick explanation:
I have the list of different āstatusesā in the first column of a table. And on any given document, click a button to see a screen that has the column of each client, and a choice component that reads from the table listing the status and writes it in the column/row for that client/doc.
Question 1: Since Iāve already started implementing it the wrong way I wonder if you have any quick suggestions about how on the back end or in an excel sheet I might do a one-time transposition of what is already there.
Question 2: Bob given what I explained above, is there a simpler way to do what you show in the second half of the video? If not, can you share your code in the javascript column with me to get me started? One other thing on this: I donāt need it to have piping or any of that. If there is a way to display the same information with existing Glide Componentsā¦fields maybeā¦? that would work
I wonder if you have any quick suggestions about how on the back end or in an excel sheet I might do a one-time transposition of what is already there.