I’m interested in hearing the opinions of fellow Gliders regarding the visibility settings for the “Show Tab Component.”
Do you believe it’s preferable to retain the current setup, where the only option for setting Screen/Tab visibility is through the User Profile table and specified validation?
Alternatively, do you think it would be more practical and versatile to allow visibility control based on values from any table, with the option to add an AND condition to check if a user is logged in when necessary?
I believe there are situations where it’s crucial to hide a screen from the general public based on certain conditions without requiring them to log in.
I’m eager to hear your thoughts on which approach you find better and why you believe one is superior to the other.
Or, is there another better way already to accomplish this?
I have an app that my clients will subscribe and pay for. There are different packages.
e.g.
Silver Package (Screens 1 through 3 are visible)
Gold Package (Screens 1 through 5 are visible)
Platinum Package (Screens 1 through 10 are visible)
Each packages enables different features for the client. Some features are to hide certain screens from being PUBLICLY available to my CLIENT’S CUSTOMERS.
My client’s customers DO NOT login at all. They just simple go to the app to browse it.
So if my Client purchase packages as follows:
Silver Package (Screens 1 through 3 are visible)
Gold Package (Screens 1 through 5 are visible)
Platinum Package (Screens 1 through 10 are visible)
How would I accomplish this and still allow my client to be able to have access to everything?
Because my client’s customers are anyone that browse the to app. So anyone that is not required login. Meaning the feature or screens available to then is based on the plan MY CLIENT paid for.
I do not want it to be dependent on my client’s customers logging in or not.
I guess I’d be curious to know how you are controlling which Client info each user is viewing. I understand the dilemma that led to you question, but I’m not understanding how you intend to control which client info is seen by which customer. I think I need to know the bigger picture here.
My only thought would be to do away with tabs and build your own navigation. Maybe buttons that navigate to tabs, or new screens, or detail screens. You can can hide tabs from the navigation bar, but still keep them active so you can navigate to them.
Thank you once again for your insights. In response to your question, each client will have their own dedicated app. This implies that each of my clients will have individual applications. Consequently, what their respective customers will see is their unique app, featuring only the functionalities associated with the package they have subscribed to. I apologize for not clarifying this earlier.
Regarding your suggestion, I was not aware that you could still access a hidden screen. My follow-up question would be: can anyone still access this screen if they knew the direct link, without going through the app’s usual navigation pathways?
If each client has their own app, why not just customize each copy of the app to hide or show the appropriate tabs based on which plan they purchased from you? I assume you are administering each app in your own glide account? Seems like you are already going through the work of duplicating and customizing each individual app. Why not just click on the eyeball button next to the tab to make certain ones visible or hidden permanently.
Yes, potentially they can if that path is available to the public and they know how to formulate the url.
I understand. This brings me back to my initial query. I have an “About Us” table that I’m using for the About Us screen. However, because Glide Apps only allows you to manage the visibility of screens from the User’s Table, I made the decision to add two columns to the “About Us” table. These columns are as follows:
PaidStatus (Boolean: YES for paid and NO for not-paid)
Paid Package (Text: Silver, Gold, Platinum, the choice of packages)
These columns are essentially checkboxes that I can use with a MAKE workflow to manage, rather than having to manually locate and hide each screen I want to hide in every app. This way, when a customer decides to upgrade, I can simply manage it in one table in Glide by checking the box(es). This would be much more convenient than having to go into each individual screen repeatedly.
I don’t think I have any suggestions for you. It seems a bit out of scope for Glide. Since the beginning when the user profiles were was introduced, and the ability to use it for global values, I’ve had the thought that it would be nice to also be able to designate a non-user specific table as a global table for cases like this where users aren’t signed in, but at the same time, I figured the use of Single Value columns to pull values from a master table would be sufficient, so I could never justify the need for something like that.
I think the problem with your use case is that obviously that you want to control tab visibility. Not a use case I’ve considered in the past. But at the same time, I can see a potential flaw with your logic. With the global user profile, it’s only ever attached to one single row. That is the row of the signed in user. But, in your case, it sounds like you would have multiple rows that you need to look at depending on the client, so how would the global values know which row in the table to look at to know which Client row should be used? I think something like that would become overly complicated and confusing to understand how to configure. It would have to be interdependent on the filter that is set on the tab. Now if you instead could have only a single row table designated as a global table, then it would be a lot less complex, but I’m still not sure how you would set it up so the tab visibility would work per client. Unless I misunderstood something and your About Us table only ever contains one single row, then something like this would be much more reasonable.
My best suggestion would be to create a feature request, but also be sure to lay out exactly how you would expect it to work. How would the table be structured? How would determine which client row to look at when setting the visibility for the tab? If it would in fact be a single row table, then I would be on board. I currently have a Resources table where I place various values that I want to reuse throughout my app, and to keep my User table a little cleaner. In that case, it’s a single row table and I just use Single Value columns in other tables where I want to use those values, but obviously I can’t use it for tab visibility and I think that would be about the only use case that I can’t find a workaround for.
@Jeff_Hager, Thank you again for giving this more thoughts.
The reason I chose the About Us table was because it had one single row and I have been using relations columns to access it where I had no direct access to it. Having a single row table like yours as a resource table makes perfect sense and very useful. This table would even be more useful if it was visible as the current User Profile table everywhere in the app and especially in the case for tab visibility.
I will definitely, put in a feature request for this. Thank you again.