Shouldnt I be able to choose this LookUpColumn?

OK, I have a table with LookUp columns, for in this case the names of the customer (LookupVoornaam).

When I make a collection on another page of this table I don’t see LookupVoornaam as a choice whereas i DO see ‘DB Naam Lookup’ as a choice.

What do I do wrong? I need the LookupVoornaam column

What’s the source of your lookup? Is it a multiple relation? It’s showing as an array. You can’t put arrays into settings that only accept single values. Your DB Naam Lookup does not appear to be an array, so that’s why that works.

Thanks, I’ll have a look!

@Jeff_Hager
Ah, I am making things too complex … :slight_smile:
When people subscribe is the moment to read the name column of the customer tab … not via the relation.
Thanks!
I have one more problem I don’t seem to be able to tackle. I’ll describe it below …

Nothing wrong with using a relation. It just needs to be a single relation instead of a multiple relation if you need the Lookup to be a single value instead of an array.

The thing is, the relation is always to 1 person. But multiple subscriptions are possible with that 1 persons. In Adalo you can choose 1 > multiple or multiple <> multiple. Don’t think that’s the case here?

@Jeff_Hager Here’s my other problem.

People can order different skates. Every skate has its own sizes. That’s why I have a tab per skate. When people order a type of skates I want them to only get the choice component that’s related to that specific skate. I have four choice components and want to show only one, the one corresponding with the skate. So in the choice component I say under visibility: only show when DB Name = … and then the custom field with DB name. But that doesnt seem to do the trick. Any suggestion?

If you need both cases, then use two relations. One that’s a single relation to get the name, and one that’s a multiple relation to get a list of multiple subscriptions.

For your choice component, are you saying that it’s not showing? I can’t quite tell which of your components on the screen bare lining up with the components in the left component panel. If it’s not showing, I would check for any extra spaces in your visibility condition and the source table for your DB lookup column. You could also try using INCLUDES instead of IS.

1 Like

All the names seem right. No spaces or different ways of writing.
When I delete the visibility options the choice component is visible (of course)
But what I was wondering:
It’s only after submitting that I write info into a table, of course. Before that, it’s not there.
Should Glide before that act with the visibility rules? In this case, i say: make only visible when screen column includes J1 (the DB name of the skate).
Sorry if I explain lousy.

Ah, ok. So it’s a form. Yes, your lookup values are going to be empty because the row hasn’t been created yet.

I guess I’m confused though. When does the user choose a type of skate? I don’t see that in your form, but I’m assuming the type of skate is chosen before they ever get to the form? Is this something in a user profile table that you could grab the value directly from the user profile? Just trying to understand the app flow and how everything connects together.

You also say that you have a separate table for each type of skate, correct? To make things somewhat easier I think it would be better to put all of that skate info in one table, add a type column, and then you only need one choice component that’s filtered by type. Doesn’t really matter though. Just a suggestion.

It goes like this:
Step 1: choose a skate

Step 2:
Choose ‘Subscribe’ (neem abonnement)

Step 3:
Add missing data in a form (data subscriber and general data skate are already there)

Those are the steps. And in the last step (add missing data) they need to say things like ‘size’ ‘date of collection’ etcetera.

The list with sizes is pretty complicated, because there are different sizes 18 for example (some skates you need shoesize, some smaller) 28 | 17,5 / 28 | 18 / 28 / 18,4 are three variations where the second bit is the footsize in centimeters :wink:

1 Like

Ok, so your form is essentially connected to the skate type that was chosen. Since you can add column value components to a form, which includes values from the parent row (chosen skate type), we know the form has some sort of access to that chosen skate type. What I don’t recall, off the top of my head, is if you can use those parent values for visibility conditions, or for a filter. I’m at work and not by my personal computer to check for sure.

I think what you might have to do is create a single relation in the skate type table to the user profile table. Then change your action on the list to a custom action, so when you click on a skate type, you first set a column value in the user profile, through the single relation, that holds that chosen skate type, followed by a show details action. Then you should be able to use that value stored in the user profile to control the visibility of the choice component in the form.

I know a guy that works for Jackson Ultima as a technical representative. :wink:

But a lot of people will get the same skates, so a single relation is not possible?

What a coincidence :wink:

1 Like

It will work. The value is temporarily stored in the user profile of the signed in user. It only needs to store that value from the time they click on the skate type, until they submit the form. It’s only used to control your choice component visibility in the form. Before and after that, it doesn’t matter.

Now if you have multiple people signed in under the same account, then yes that will be a problem. But otherwise, they are only updating their own user profile row.

1 Like

So do I understand it right? I make sure there is a relation between ‘skate’ and ‘user’ and use that relation to write skate type in a column and use that skate type for visibility?

And does this work as well when someone buys more than 1 subscription after another because of children/family?

All you need is a template column that pulls in the signed in user’s email. Using that template you create a single relation to the user profile table.

When you click on a skate, you first call a set column action that places the selected skate value into the user profile. This is done through the single relation. The next action takes you to the detail screen for that selected skate.

If I’m understanding the flow correctly, if a user is adding multiple subscriptions with different skates, then I assume they are selecting multiple different skates, and submitting the form each time, correct? Every time they select a different skate, it will replace the selected skate value in the user profile, and every time the form is shown, that selected skate value, in the user profile, will be there to use in your visibility conditions.

Phew!!! Thanks so much @Jeff_Hager !
I have it working!
It took a while, but this slow student finally gets it :wink:
Learning by doing!
Thanks so much!

3 Likes

When you click on a skate, you first call a set column action that places the selected skate value into the user profile. This is done through the single relation. The next action takes you to the detail screen for that selected skate.

One extra question, @Jeff_Hager
Your way of working is great if you’re signed in as a user
When you’re new or not signed in, now you don’t have an effect when clicking. So you can’t see a detail page.

If I want that, and I do :wink: what can I do?
Make a new action that has those steps a phase later in the ‘subscribe’ stage?
So ‘when click on subscribe’

  1. set column action to the user profile with the selected skate
  2. view the edit form for missing data (size etc)

On submit go back?

Would that be a possible route?

Is it safe to assume that a user has to be signed in to complete the edit form?

I think what you are suggesting would work. (You may lose your form if the subscribe button doesn’t already use a custom action, so I would advise creating a new button so you can copy the existing form components.)

First set a custom action to the subscribe button. Put an IF condition in the action that checks if the user profile email is empty. If it is, then show the sign in screen. For the Else, add your Set Column and Show Form actions like before.

I suppose you could also hide the Subscribe button altogether by checking if the user profile email is empty. Then you wouldn’t need the IF condition within the custom action. Depends if you want to see the subscribe button all the time, or only when the user is signed in already.