I want a tab to be visible or not based on the data in a column of the corresponding sheet/table.
But am I right, is that not possible? Is it only possible based on user profile info?
If so, what is the logic behind that?
And how to get around it? 
Can you explain your use case a bit more?
The use case is this:
I built a site where people āleaseā skates. There is a special section called āNordic skatesā. People go to section either via a button (with hint component) on the homepage or via the tab in the navigation.
The owner of the site wants to be able to hide all info about āNordic skatesā with the push of a button on his āadminā page.
I have that now up and running for the button and the hint on the home page via the setting of a custom value.
The same thing I would expect to be able to do with the tab.
Okay, got it.
So all you need to do is import that ācustom valueā into your User Profiles table, and then you can use it to drive the tab visibility.
How you get it there depends. If itās the first row in a table somewhere, then a single value column would do the trick.
The only thing is people can visit the site and look around without login in. So it shouldnāt be there for not logged in users either.
Okay, so I guess the other option would be to just hide it from the menu.
But, just taking a step back, maybe a better approach would be to have a āNordic Skatesā section on your tab that lists all skates, and then just hide or show that section. As opposed to having a whole tab for Nordic Skates.
There are three types of products:
- Lease skate (a subscription on skates, you pay automatically per month).
- Rent skates for specific school holidays (pick a week and pay for that week).
- Rent Nordic skates and pick your own period (startdate / enddate) and pay for that period.
Maybe I could do everything in one table, but to me that feels more complex and too many columns. For me it feels better to split the different types of renting.
And something else: do you have an idea why tabs are only related to user profiles where components / containers, etcetera donāt have to be?
And I donāt want the client to go in the admin section, but when necessary I can hide it myself, thanks!
No, I donāt. Iāve never really thought about it.
1 Like
I would guess itās because a user profile row will always be one specific row, tied to a specific user, that is globally accessible, whereas the source table for a tab could be multiple rows with filters or row owners. If thatās an option, then which row would be the source of truth for the tab visibility conditions? Would it be the first row, the last row, or any row in between? Would you respect any filter or row ownership applied to the tab when determining tab visibility, or always ignore them. I donāt think itās as straight forward as using the user profile.
Back before user profiles were added, I seem to recall that there was discussion about having a global table for things like this, and to store globally accessible values. When user profiles came out, they were a pretty decent compromise. Iāve thought to push for a global (non user) table, but could never think of a valid reason to have one. Most scenarios can be worked around one way or another. However, this seems like a good use case. Iād rather see a generic global table that can be used globally, just like the user profile, but available āin addition toā the user profile for cases where a user is not signed in. If thatās not reasonable, then maybe it would be useful to have a way to create a special user profile row that is for non-signed in users.
4 Likes
Yeah, valid points!
1 Like
Hi!
For using case, where you need to deal with non login users( but login is a option)
usual i creating separate table with single row and all user-specific columns.
All another tables can write to it by adding single value column. to whole row (table with single row U-S)
And all tables can access to data throw common single value to this table
So you can have user row for not logging users and use it for visibility anywhere.
1 Like
Yeah, thatās one of the workarounds that I have used. Only problem is that it will work for for anything EXCEPT Tab Visibility.
Oh, yes, sorry, I really forgot it!
1 Like
There was a brief discussion about this other day in the experts slack group, which you might have missed. A good use case for a āGlobalā table I think is with Public Users. Yes, there are ways to work around it, but itās more mucking around than it otherwise could be.
2 Likes
Yeah I might have glazed over that or missed it. Iāll check it out.