Being able to filter by %user_email% or something like that for situations where you’re using lists that are related and you want to filter a list by entries that are for you and entries by you.
Eg.: A list of the “requests initiated by me” and a list of “requests done to me”
I have seen a variable like this on chats before. Would be good to have something like that
You can do this already.
https://docs.glideapps.com/all/guides/intermediate-techniques/per-user-data
Hi Jeff. Can this be used on a detail page with an inline list?
I believe so. Just turn on per user data for the detail view as well as for the inline list. Try it.
Otherwise you can set up a reference to link the detail you are viewing to list you want, but if you are only worrying about the email, per user data will work just fine.
I’m looking for a similar thing,… @Sandro_Brito did you get it to work?
My issue is:
My app is close to getting used but I’m running into a final problem,… https://bxbbu.glideapp.io if you’d like you can pass me an email address and you can get in the app.
Manifest has many Bookings
Bookings has many passengers
Manifest has a pilot and a plane
Planes are there, Pilots are the ones logged in. Pilots create passengers, and they create a Manifest.
Pilots add Passengers when they are inside the Manifest with a form + Choose from list -->
This list is populated from Passengers and shows ALL passengers, not only the ones create by the Pilot.
How can I solve this?
If you have a view and a dependency second view. So view1 has many view2’s.
Using the inline list will show one item from view and many items from view2.
Get I use that view2 list as and option list where people can select 1 or many option to post into a different table?
Because so far for posting data I haven’t been able to use the inline stuff usefully other than displaying it.
To answer your first question, I can’t think of a great way to filter a Choice component on a per user level. There is some discussion in this other thread that would possibly make it possible, but it is not a user friendly process and there would be a lot of overhead and gotchya’s that I haven’t thought of. I may experiment with this in the next week or so.
To answer your second question, I’m having trouble visualizing what exactly your asking, but if you are in a detail view and you use the Form Button to add a record to a sheet, you can include the column values from that detail view in the form submission.
Thanks @Jeff_Hager,… I’ll go experiment with option 1 as well.
As for the second question,… What I’m trying to ask is if an inline list can be used with a selection box in front,… so then you could submit a selection of the inline list in a form post (other sheet).
Basically trying to get the same thing done as the first option through a different control.
Here is a screen recording of what I’m trying to do,… I feel a little stuck at the moment,… any other nudges / tips / tricks for me to try? https://www.dropbox.com/s/1ejos8um0md137e/Screen%20Recording%202019-10-10%20at%2022.14.38.mov?dl=0
So close you can taste it. Excellent video and excellent app.
You’re first option with the form button is obviously the best, but with the limitation seeing other users passengers.
For your second option, what you could due is create a duplicate sheet of the passenger sheet. That new sheet would be the one you show on the Manifest details page. When you open up the details for that passenger, then you could add a form button that would not show on your original Passengers tab. The only problem is you would have the passenger information in the form, but then you would still need a Choice component to select which Manifest to add the passenger to. It would just be the reverse of the problem you are trying to solve.
I really hope that per user data becomes an option for the Choice component in the near future with further filtering and sorting options later on. I would also like to see the Column Values expanded to show column values from higher up in the hierarchy. That way, if you have lists nested within lists, you could pull values from the first list after you’ve drilled down.
I would prefer option 1, but I will contemplate this for awhile to see if I can think of a better solution.
Kind words! Thank you. I’ll add some text here and there and release with this “feature”.
@Jeff_Hager I’m kinda new here,… with requests like these,… even though they’re discussed here, do I need to add a new tickets with a feature request?
Where are the passengers for a given flight stored? It looks to me that you are missing a sheet. In my mind you would have: Pilots, Planes and Passengers. Which you have. In my opinion the Manifest should only hold who is on a given flight. It would simply have a flight ID and and Passenger ID’s. Then you would have a Flights sheet, which I think you are now calling a Manifest. A flight manifest is:
A flight manifest is a list of passengers and crew of an aircraft compiled before departure based on flight check-in information.
The Flights sheet would have the information about, what plane is being used, where it’s going, where it’s starting from, the date and time of departure, etc. It’s a singular thing, there is only one flight. The manifest, can have just one or many entries for a given flight. It is a list of what passengers are on a given flight. (Note: You could have the pilot on the Flights record since you only have one in your case and no other crew, so the manifest would just have passengers for a given flight. But a “real” manifest would have passengers and crew per the definition of a manifest.)
Another thing that I’m not fully understanding is why passengers are specific to pilots. I’m sure you have your reasons but I’m thinking of this application being one that a flight service would use. This company would have pilots, planes and customer lists (those passengers that had booked prior flights with them.) When a fight was booked or created the administrator would first create the flight, picking the plane, out of the planes available, and then the pilot, from a list of pilots that know how to fly the plane scheduled. Then they would select which passengers would be on the flight.
I guess you are thinking of it as more pilot central. A given pilot owns or has access to a given plane or planes. They also have a set number of “regular” passengers that they would normally fly with.
I realize this has nothing to do with how to select passengers but I’m just trying to clarify things and find out the ultimate use case of the application.
Excellent question. In this case the airfield is giving pilots a badge. But every GA pilot bringing a passenger needs to have the passenger on a manifest.
So in this case passengers are friends / connections of the pilot. Fellow pilots would now be able to see the other passengers.
My sheets will crash if 2 pilots bring the same friend. So I might rework that part.
Still doesn’t fix the selecting part but at least you have more context.
@George_B I have the sheets you mentioned
Standard Pilots, passengers, planes.
Manifests - basically holds all sheets together
Flights - should be called differently, it’s basically a flight log per passenger.
But maybe I should read yr answer again to see if I get the point.
The way I understand it, rather than entering passenger information from scratch into the manifest, he wants to select passengers that have flown on previous flights. So in essence, the passenger sheet is a dual purpose sheet (a list for the manifest, and as a list to be chosen from to duplicate the information into a new manifest). I would agree that another sheet should be created, but only built using UNIQUE from the original passenger sheet. Otherwise there would be duplicated passengers in the choice component.
I do get the selection of passengers from a list, and honestly am not adding to the prior possibilities of how to integrate that into the app. What I’m suggesting is that each flight should have a row in a Flight sheet. The Manifest sheet should only have essentially two columns of data. A Flight ID, that links back to the master Flight sheet, and a Passenger ID, that links by reference back to the Passenger sheet. I agree that the Passenger master list would only have unique Passenger/Pilot entries. I say Passenger/Pilot instead of just Passenger because this would allow for the same Passenger to be a passenger of two or more pilots.
@Naos_Wilbrink I’ve been going through some old posts that I had bookmarked and I came across this thread again. I’m just curious if you ever got your issues resolved. A lot has changed in Glide since October (especially filtering and per user data for choice components). Just wondering if you were aware and got your app to work. Hope all is well.
My dating app requires a male user and a female user to purchase a date SKU (booking at a restaurant), so I have a relation column that matches SKUs from the App: Sales sheet and puts both of the purchaser’s emails in a column separated by a space … and then I filter based on the per user data to show the confirmation of their paid SKUs … but even though the first person’s details shows in the preview as screen, it doesn’t show in the actual app, and the second person’s doesn’t show at all. I’m assuming it’s because even though it “contains” their user email, the field does not equal their email. Is there a way of filtering based on a column that “contains” rather than “is” user email? Or is there a way of splitting a relation column into two separating on the space?