Hide Elements When User Not Signed In

Thanks Robert, much appreciate your help. Although this is a little over complicated for my app. Trying to keep things quite simple.

For you, what constitutes “having a profile”?

Do you have any screenshots of what’s not working? It’s a should be a pretty simple process, but it would help if I could see what you have for your relations and lookups so far.

1 Like

@Robert_Petitto – spent a while with this video and can’t figure out how you created a relation between your players (customers in my case) and other pages in your app.

Would you mind sharing?

Not at all!

  1. In the user profile sheet, create an if then column (I name mine “hasProfile”) that will result in “true” when your desired user fields are not empty.
  2. In the other sheets create a template column (I name mine “profileTrue”), and give it the static value “true”.
  3. Then in these sheets, create a multiple relation (I call mine rel_hasProfile) to the hasProfile column in the profile sheet.
  4. Do a lookup to grab the users’ email addresses (I call it profileEmails).
  5. In your layout view, create visibility filters on components where “profileEmails is (or is not) signed in user”

Is signed in user? Show your app components
Is not signed in user? Show text/form buttons/etc to get your users to fill out their profile.

Thank you so much! I think #1 is where I got stuck. Your process worked for me.

Do you think this would work for phone numbers in place of emails? So instead of looking up an email, looking up if a column has a phone number.

Then hiding components if the phone number column is empty / showing components if the phone number column is filled.

No, I don’t think so. Until Glide comes out with user specific data, Glide can’t filter out users by phone number…only email

Hm , I understand. I’m looking to filter people out of content until they’ve submitted a phone number. I I thought I might be able to filter people by their email address to lookup if they’ve submitted a phone number, and then show/hide components. This seems to be the closet I can get!

Thanks so much for your help.

Quick follow-up question: If privacy settings are set to Public with Email, aren’t these already hidden?

Perhaps there is another way to login that I’m missing.

You’re correct. You can make one of the conditions of the hasProfile column that PhoneNumber is not empty…but the component has to rely on email is signed in user to filter.

Aren’t what already hidden? The Email addresses?

I have my app set to Public with Email. So I found that when I set everything in my app to hidden unless logged in that it had no affect, because no one can access my app without email.

I then attempted the above steps with Show component when a user has not completed their profile, but it wasn’t working as expected.

My goal is to have an onboarding screen for a user to fill-out a form with their name / phone. (I should have their email from the login screen).

I want that screen to then be removed after the form has been filled out, and show my welcome screen.

Hope that makes more sense!

It does! I assume you want your onboarding screen and welcome screen to be the same tab. What does your user/profile sheet look like? Are you bringing in their email addresses from the App: Logins sheet? I’d need to see your data tables to see why things aren’t working as expected. I’ve done the process I outlined above 2 dozen times, and it works.

That’s good news! I’ve attached screenshots below of my customers screen (with the Profile If Then Else), as well as my home page screen with the steps you listed above.

I’m currently pulling in email addresses as a special value, but I’d prefer to do that in the App:Login page but am not sure how.

Screen Shot 2020-04-05 at 7.29.42 PM

Just realize that you are setting visibility when anybody has a phone number. If I sign in and do not enter a phone number, there are still other’s that have entered a phone number and the components will show for everybody because 1 person has entered a phone number. You really can only use the lookup with emails to compare the array of emails to signed in user. Your profile sheet should only set True to a record once the phone number has been filled in the profile. Then your relation to the profile sheet will only find profiles where the value is true and the lookup will only return the emails from the relation that have have had a phone number filled and the value in the profile sheet set to true. The array of emails are what you use to check if signed in user.

1 Like

Hey Jeff –

I just adjusted my profile If This Then to only look for phones and return true when they are present.

I’ll check to see if that made an impact for viewing!

@Jeff_Hager That was it! The signed-in users was a big question mark for me, but that cleared it up.

I imagined signed-in users were always = all signed in users.

Is there any benefits between bringing in emails to my users sheet from the App:Login screen or does special values achieve the same end?

1 Like

You are comparing a column value to signed in user, so it’s looking for a match in that column. Otherwise with your original thinking, there would be no point to compare to a specific column. It would need to check if the user is signed in or not (there is no such check).

As for benefits, that depends on your use case. Bringing in emails from App:Logins eliminates a step for the user by automatically creating user specific rows, but you run a risk of emails shuffling around if you use the Unique formula and delete or sort the records in app:logins. If info is personal, you do not want to run the risk of the unique formula reshuffling the emails and creating mismatched data for each email.

Using the email special value is better, but the user has to first submit a form to create their own user record by writing the email special value to the sheet.

There are scripts you can use to write new user emails to a sheet. I use one to similarly copy new names to several other sheets. This automates the process and eliminate the user needing to submit a form, but complicates things by introducing a script.

Ultimately you shouldn’t need any of this once user specific columns are released, but I don’t know when that will be. I’m hoping within a few weeks. In that case we’ll be able to store values from several users in a single row cell.

In the end you pick what works for you. Many people have began creating user specific rows by submitting a form with the email special value.

2 Likes

Very thorough explanation…thanks @Jeff_Hager.

3 Likes

Thanks @Jeff_Hager! Sounds like its ok for me to keep the current setup, but might upgrade it in the future.

1 Like