Tab visibility not working - any insight?

Hi All,

First-time poster. I’ve been reading through the community postings for weeks now while learning Glide, and it’s been such a huge help, thank you. My biggest issue I can’t seem to solve is getting Tab Visibility to work. My app is “Public with E-mail” and is a directory of people which consists of:

  • A “Welcome” screen tab with a register button which opens up a short form asking for the user’s name and title and a checkbox that must be ticked to submit the form. (I created a Glide-only table called “User Data” in Data that captures this form information.)

  • Tabs that list the actual directory (a tab for All, a tab for Available, a tab for Advanced Search…side-note thank you @Robert_Petitto I was really stuck on advanced filtering before finding your video! :star2: )

  • A “My Profile” tab where a user can view and edit their profile IF they are contained in the directory. (The app is meant to be used by members of the directory as well as outsiders.)

WHAT I WANT TO HAPPEN:

  • First-time User logs in and is only shown the Welcome tab, where they click to access the registration form and submit their name, title, and click a checkbox (all are required).
  • Upon submission of form, the Welcome tab disappears and the other tabs appear, with the “My Profile” tab only appearing if the e-mail of the logged in user matches e-mail address on the directory Google sheet. (The “View Profile” tab itself is the detailed view of the directory, filtered to only show and be edited by the logged-in user, and this functionality works as intended.)
  • Existing user (who has already submitted the registration form in a prior session) opens the app and does not see the “Welcome” tab, and can see all other tabs including, if they are in the directory, the “My Profile” tab.

WHAT IS HAPPENING:

  • “Welcome” tab appears by itself but after submitting the form it just goes back to the Welcome Screen, with no other tabs appearing. Note that the form is successfully populating the “User Data” sheet.
  • If I start over and Preview the app as someone who has already submitted the form, I am still only shown the “Welcome” tab and no other tabs.
  • “My Profile” tab does not show up “when e-mail is signed-in user” when I am previewing as a directory member. Oddly it does show up when I change that to “is NOT a signed-in user”?!?!?! (Because of above I had to turn off the other tab visibility settings to discover this tab’s failure)
    .
    .
    .

SCREENSHOTS OF CURRENT SETTINGS:

Screen Shot 2020-11-01 at 3.49.20 PM
:arrow_up: I attached the User Profile settings to a sheet called “User Data” with Row IDs that lives only in Glide. I set the e-mail address writing to Email using a “special value” component in the registration form for my testing purposes, only because I wasn’t sure how reliable the “Preview As” e-mail is recorded in draft mode? (I wasn’t seeing it recorded in “User Data” until I used this method.)
.
.
.


:arrow_up: My settings for the “Welcome” tab - “T & C” is the form checkbox which is a column in the “User Data” sheet.
.
.
.

:arrow_up: My settings for all three various tabs that list directory members…
.
.
.

:arrow_up: My settings for the “My Profile” tab which I only want to be viewable to people listed in the directory. I have a relational column paired with a look-up column in “User Data” which retrieves the e-mail address from the “Directory” to match it to the current user when applicable.
.
.
.
TROUBLESHOOTING QUESTIONS:

  1. Does Tab Visibility not work on free apps? I read that automatic changes to sheets don’t refresh on free apps, but the changes made by the form submission are not at sheet-level, they are at Glide-level. Also the documentation only references things like formulas, not form submission.
  2. Does Tab Visibility not work unless the app is published? I am fully in draft-mode and testing this functionality by previewing as different users - but am a little unclear on whether Glide is consistently referencing my own “User Data” Glide-sheet for visibility functionality, or if this functionality relies on logs created once the app is published?
  3. The only reason I even pursued this complexity is because the very very first time I tried out visibility was in having the Welcome screen disappear upon form submission, and I swear it WORKED that very first time, just never since. Is there an invisible Glide log at play here?

Thankful for any insights and for reading this long post!
.
.
.
:memo: I feel I should note that I am not a sneaky company or commercial entity that’s benefitting from this app - it’s a personal endeavor to help out a zero-funded group I belong to and unfortunately it has to remain in the “free” realm…

1 Like

I think the main issue is that a Glide Table can’t (or shouldn’t) be used as the User Profiles sheet. I don’t think the process is working properly right now. EDIT: this may have been fixed but I’m not 100% sure. I know it used to be an issue, but may have since been fixed.

The other issue is that you’re writing the email to the User Profile sheet — when the user logs in, Glide should automatically be putting their unique email address into the email column, then you can have a details view in the app that is filtered by signed-in user where someone can enter text fields to populate the other columns in your profiles sheet. If you do it the way you’re describing, you’ll likely result in multiple email entries for each user in your User Profiles table, which will cause visibility conditions to be wonky as I think they probably look for the first instance of the e-mail address in the table and use that row for the conditions.

1 Like

Hey, thanks for the reply! My thoughts:

I hope the Glide table issue was fixed, especially since I’m allowed to assign it as the User Profiles sheet :crossed_fingers:t2::crossed_fingers:t2::crossed_fingers:t2:

The reason I’m forcing the e-mail into the User Profiles sheet with the form is that it’s NOT going there automatically when I switch e-mails in the “Preview As” setting. I think Glide automatically logs it only when a user signs in on the initial sign-in screen? So I thought to re-sign in with different e-mails, but whenever I try to sign OUT to re-access that screen, the page simply reloads into the same signed-in state I was on. I tried signing out in Safari, Firefox, and Chrome - all just reload to the same signed-in page. I can’t tell if this is a bug or just Glide’s way of saying that I can only switch users with the “Preview As” setting (which again, does not log the e-mail I enter there into User Data)

This is why I thought maybe this was all impossible to test in draft mode - though that seems silly, I shouldn’t need to publish an app to test it.

I know my app would be a lot simpler if the directory sheet was also the User Data sheet, but I really need to keep the app users separated from the actual directory sheet. I feel like this should be possible.

THIS JUST IN - I just noticed when I go to the My App dashboard in Glide, underneath my app name it says “No user data” - is this a clue??? If I’m not actually generating user data despite assigning a sheet for it, that’s a problem? EXCEPT - visibility settings within the tabs themselves have consistently worked perfectly when using the condition “is signed-in user” - it’s only tab visibility that refuses to work. So it seems Glide is keeping track of the e-mail I’m previewing-as but not showing me WHERE it’s doing so, and logging nothing else. This is all very confusing :expressionless:

If you don’t use your app in a “real” way (i.e publishing it and going into the app by signing in like a “real” user) then it won’t populate, I guess.

I assume you’re only signing in and out in the editor?

As Kyle said above, you should never use a form to populate your user profiles sheet as it will lead to duplicated rows for each email.

1 Like

Those are just stats/analytics on app usage. If you haven’t published your app and nobody is using it, then there are no stats to show.

As the others have said above, using a form as well as well as the user profiles feature will most certainly cause duplicate records in real works use. Make sure you don’t have duplicates in your sheet.

Preview As is not a sign in process. It only previews as if you were signed in as that user. If they already have a row in the user profile sheet, it will use that first matching row for the tab conditions. If they do not have a matching row in the profile sheet, then it will react as if there is not profile.

2 Likes

Hi @a.manda,

I’ve just been through an almost identical exercise, and I also struggled. But I did eventually get it working, so will share my experience and maybe that will help.

Firstly, I found this tutorial from @Robert_Petitto extremely helpful (note: have a read of the entire thread, as I think much of it is relevant to your situation).

In my situation, I too wanted to keep all tabs/screens hidden from new users until they had met the minimum profile requirements. This is how I (eventually) achieved it:

User Profiles sheet: I just added a single Has Profile column as a Number type.

For the onboarding landing page, I created a new tab and linked it to my User Profiles sheet. Tab visibility for this sheet is set to Email is signed-in user and Has Profile is empty

For the layout on that tab, I chose the Details layout and deleted all the default components. In the Features section, I set the filter to email is signed-in user. (NB. This is important, otherwise you end up with each new user editing the first row in your sheet. I found this out the hard way :crazy_face:)

I then added appropriate entry components to the layout: text entry for name, image upload for profile pic, etc. I didn’t do anything special with those components in terms of visibility/filtering/etc.

The final component was a “Done” button. This was a button component with an increment action of +1 on the Has Profile column in my User Profile sheet. The other thing I did with this button was to set the visibility so that it only appears when the User Name was not empty, like so:

In my case, I kept it simple and made only the name mandatory. If you wanted to make extra attributes mandatory, you could simply chain more conditions, ie. Name is not empty AND Location is not empty

Here is what my onboarding screen looks like:

Note that the ‘All Done!’ button is initially hidden, but as soon as the user starts entering their name the button visibility condition kicks in and the button appears. The user can then either fill in the rest of the info, or just skip straight to the button. Once the button is tapped, Has Profile is incremented and the screen disappears.

For all the tabs that I initially wanted hidden, I set the visibility to Email is signed-in user and Has Profile is not empty.

For testing: I also found what seemed like weird and inconsistent behaviour when trying to test this from the data editor (after reading this thread I think I understand why now), so I’d recommend publishing your app and get an extra email address to use as a test account.

Hope this helps,
Darren

2 Likes

Very well written Darren, and hit all the right notes!

2 Likes

Thanks @ThinhDinh :slight_smile:
Interestingly, composing that helped to consolidate my own understanding of what’s going on. I believe that’s called the “teddy bear effect” :smiley:

2 Likes

THANK YOU, Darren! Gonna comb through this, process, experiment, and report back :crossed_fingers:t2:

1 Like

This is exactly what happened to me after formulating my question :joy:

1 Like

That’s the thing - the editor does not allow you to sign in and out. It lets you click “sign out” but then nothing happens except a page reload where you’re still signed-in. And yes, I know to not use the form method IRL (by which I mean - in published state) - I just needed a way to populate the user profile sheet to test functionality because it’s not happening with “Preview As” (arghhh)

Thanks Jeff, that’s so helpful to know re: stats/analytics and the Preview As functionality!

Yes I know not to use the form method after publishing - I only enacted it because the “Preview As” feature is not populating the e-mail address into the user profile sheet, and without the e-mail address logged I had no way to test my Tab Visibility settings. Once the app IS published though, the e-mail used to sign in would automatically populate that user profile sheet, right? I thought? (If I’m mistaken I need to completely rework this)

I have tested the Tab Visibility in situations where the user does already have a row in the User Profile sheet (from the temp form submission method) and it still does not work…I thought maybe the form submission wasn’t resulting in a data-refresh to where the app could recalculate the visibility conditions, but even when I Preview as a user who already completed the form in a previous session, the visibility settings still don’t work as set :expressionless:

Also of note - my User Profiles sheet started out completely empty - it is solely to catch users logging in to use the app. No duplicates exist, it currently only holds lines from the form submissions (meaning after publishing it would only hold the lines of users who have signed-in). The actual directory of people is a separate sheet - I do have a relation set up so that the app knows when the logged in user matches a person in the separate directory. Am I allowed to use the User Profiles sheet in this way? (Once again - if I’m mistaken I need to completely rework this!)

1 Like

This is true.

What are your settings for the tab visibilities as of now?

I think you don’t need to have a separate sheet, just make a boolean column and add an “and” condition in there.

Hey All,

I wanted to come back and report my findings, especially for future thread readers having the same issues. After testing and changing things around, I discovered that:

  1. @shchc you are correct - a Glide-owned table can NOT be used as the User Profiles sheet. I feel this should be documented clearly by Glide, or better yet corrected as it actually plays out as a bug. From what I can gather any auto-calculated column within a Glide-residing sheet can not successfully be referenced within the app. This is problematic since my Google sheet is populated directly by the directory members, and I don’t want them having access to the User Profiles sheet but now I have no choice. Hiding the User Profile data inside of Glide seems like a perfect use of the Glide-only sheets. I honestly assumed that was their point when I first discovered them.

  2. Tab visibility based on user profile data does not work unless the app is published. I was trying to get around this possibility by forcing population of user data with my temporary form, but somehow Glide knows the difference - once my app was published, real user profiles were generated on separate lines from my fake ones. @Darren_Murphy thanks for the link to @Robert_Petitto’s tutorial where he clearly spelled this problem out back in April. Again, a bug in my opinion! What’s the point of builder mode if you can’t truly test an app’s critical functionality? @Darren_Murphy thank you also for sharing your increment method, once I switched from form to components for onboarding I needed that and it works great.

Glad to have my tab visibility finally working, but also frustrated by the lack of functionality that I believe any beginning Glide maker would assume was available - using Glide tables for user profiles and being able to fully test an app without publishing it.

Thanks everyone for all the helpful input!

1 Like

Is this still the case?

Can’t say this for sure but I have seen people using that in the past few months. Glide also released a Glide Table only choice to start an app so I assume this must be available.

I have some glide-only-table app, and I use normally one as user profile sheet

Sorry to have missed this earlier, but for anyone reading this thread down the line - Glide DID fix this issue shortly after I struggled with it - yes you can definitely now use a Glide-owned table as a user-profile sheet :clap:t2:

1 Like