My application is currently set to “Required sign-in,” and I need to switch it to “No sign-in.” However, when I test as a user who is not signed in, two features stop working.
For context, here’s a description of these two features:
The application allows users to search through an inline list, but the search box is grayed out when I’m not signed in. Instead of using the built-in search functionality, I’m using a text input component that stores the user’s input, which is then computed before being used to filter the list.
The application also allows users to favorite and unfavorite items in the same list. Currently, when I’m not signed in, these buttons don’t appear, even though I haven’t set any visibility conditions. Note that clicking the “Favorite this item” button writes to a boolean, user-specific column in the sheet containing all the items. Also, in the user sheet, I store a count of favorited items for each user and use this count to determine whether to display the list of favorited items or an empty state that invites users to start favoriting items.
Now, when a user is not signed in, I’d like to display a call-to-action inviting them to sign in to use these features. For instance:
Instead of the grayed-out search feature, I’d like to display a button that says something like “Sign in to start searching using AI.” Clicking it would lead the user to a sign-in screen, and once signed in, the user would return to the initial screen.
Instead of making the “Favorite this item” button disappear, I’d like it to be visible, but when users who aren’t signed in click it, they’d be led to the sign-in screen.
Let me know if anyone has experience with achieving this type of behavior and could guide me through the approach/steps. I’m happy to answer any questions that might help clarify my situation.
Sounds like you are utilizing the user table for this search functionality. If a user is not signed in, then they are not attached to a user row. You should use a generic table with user specific columns for the screen that has this search functionality.
If a user is not signed in, there is no associated user. You can still populate user specific columns, but they are going to wipe out when the app is closed.
That’s easy enough with a button that has a Show Sign In action. You may or may not need to add a visibility condition to only show it if the user profile email is empty. But like I said above, with a little restructuring you can still make the search function work without the user being signed in.
All you need to do is create a new custom action on the buttons, with an IF branch to either update the row or show the sign in screen based on if the user profile email is empty or not.
Sounds like you are utilizing the user table for this search functionality. If a user is not signed in, then they are not attached to a user row. You should use a generic table with user specific columns for the screen that has this search functionality.
I’ve set up the columns in the items sheet to mirror those in the user sheet, including the user-specific user_input column where the text entry component records data. The other columns I ported over are designed to process the user’s input and determine if it matches any of the items.
However, the text entry seems to only populate the first row of the user_input column, leaving the other rows blank. I’ve changed the components in the layout view to write to and read from the new columns but the filtering doesn’t work. I assume it’s because the user’s input isn’t recorded in all the rows, preventing the matching logic to work for all the items.
I’m adding a screenshot of the user_input column’s settings in the items sheet.
Second, about the “Favorite” feature:
All you need to do is create a new custom action on the buttons, with an IF branch to either update the row or show the sign in screen based on if the user profile email is empty or not.
I’ve added an action below that I had made after reading about a similar issue on this forum. It looks like it’s what you’re talking about, but the button still doesn’t show up on the page.
I thought maybe some visibility settings were hiding it, I don’t have any in place. Am I missing something else?
That would be expected. A screen can only be connected to one row at a time. The entry components would only affect columns in that one specific row. Wouldn’t it be the same situation when you use the user table, where a search value would only be written to the column in the signed in user’s row? I would think that you would be setting up any relations or filters the same way, but they use the screen values from from the current row that the screen is attached to. Maybe that’s the issue…you are using table values and not screen values.
While you can use the item table to hold your user specific columns, and there is nothing wrong with that, I tend to prefer creating a separate single row table for this purpose. Not important for now, but something to keep in mind.
Hmm, It looks like you have the action configured correctly. Out of curiosity, are you previewing the app in the builder as a specific user, or as ‘anyone’ (which is the same as not being signed in). Also, do have you tried in the published version of the app?
The first step would be to determine which action is not working. Try replacing one or both of the actions with a notification action. I’m curious which branch it’s falling into.
I’m struggling to understand my options. I’m still fairly new to Glide so I have a few more clarifying questions here:
What do you mean when you say “you are using table values and not screen values”? Would using screen values help resolve the issue?
It sounds like one solution would be to use, as you say, a separate single-row table which wouldn’t require the email and hold the user_input data. Is that right? If I’m understanding this right, it sounds interesting. Am I understanding it right? If so, when you’ve used it, have you experienced any drawbacks I should be aware of?
I imagine another option is to somehow hide the search function from users who aren’t signed in and have some sort of call-to-action to invite these people to sign in to access these hidden features. I’m not a fan, as I think search is pretty basic and I’d like for everyone to be able to access it.
2) About the “favoriting” feature
I’m replicating the behavior when I set the app as “No sign in”, both in the layout view as “anyone” as well as in a separate incognito window.
I have three buttons. The first two images are for favoriting and unfavoriting respectively. These two actions are subject to a condition: you can only favorite an item if it is isn’t already checked as favorited in the items sheet, and vice versa you can only unfavorite an item that is checked as favorited. I tried removing these conditions though, and it doesn’t change anything.
The third button is associated with a simple “Sign in” action. I tried added a visibility criterion to show the component when the email is empty in the users sheet. But regardless, the button doesn’t appear when I’m viewing as “anyone” (or in an incognito window).
Not sure what I’m missing. Any ideas? I hope those details help a bit.
About the second point around “favoriting”, I actually noticed that the button appears up until the point when I add the “email is not empty” condition above the “set column values” action. If I remove that condition, then the button appears.
It might be useful to see screenshots showing how you have your search functionality set up. I’m making a lot of assumptions, so I don’t want to lead you down the wrong path if I’m telling you to do something that is completely different from how you actually have it set up.
When you use a screen values in your filter, it’s pulling values directly from the row that the screen is attached to. If your filter is just comparing column to column from the table, then it’s going to compare those values in each row. If you previously had your filters set up to compare to values in the user profile, it’s very similar, but instead of selecting the user profile, you select the screen values.
This is my person preference. I’m under the assumption that you had user specific columns in your user table, and instead move them to the same item table that you are also trying to filter. That’s fine. Not my preference, but not a big deal.
No drawbacks. It just keeps other tables cleaner without a bunch of extra columns. There is only one row that needs to perform computations. The user table is nice in some cases because user profile values are easily accessible, but I usually still have a separate driver table for certain screens
That’s an option too if that’s what you choose to do. To me, search is such a basic function that it doesn’t seem intuitive to hide it.
Have you actually tried my suggestion to replace either the Set Column action or the Sign In action with a notification. It’s still unclear to me which path it’s going down, so I’m not sure which action is failing. How is your action IF condition set up? Are you looking at the email from the user profile?
It might be useful to see screenshots showing how you have your search functionality set up. I’m making a lot of assumptions, so I don’t want to lead you down the wrong path if I’m telling you to do something that is completely different from how you actually have it set up.
I’m adding screenshots below to show the settings behind the text entry component and the column types I’m using to match it with the items (i.e., emotions in the case of my app).
Settings of my text entry component in the layout view
Columns I use in the users sheet. The logic is that I store the user’s input, format it as a prompt, process it through an OpenAI integration that returns matches.
Column in the items sheet where I then check to see if the data in the users sheet matches any of the rows in the items sheet.
I tried to use a single-row sheet but I’m not sure how to connect it with the text entry component. This component lives on the same view as the filterable list of items and that one is built on the items sheet.
Hopefully these new details will help you understand my set up. I welcome any ideas.
Have you actually tried my suggestion to replace either the Set Column action or the Sign In action with a notification. It’s still unclear to me which path it’s going down, so I’m not sure which action is failing. How is your action IF condition set up? Are you looking at the email from the user profile?
I finally got what was preventing my solution from working. It was because I was switching my app’s privacy setting to “No sign in” and not “Optional sign in”. With the latter, the “Sign in” navigation action behind my button–the one I display when the email is empty in the users sheet–wasn’t working.
Now, I can either use this solution which sends the user directly to the “Sign in” screen, or I can first show a notification (e.g., “Sign in to start saving”). It’s more of a user experience consideration, but the second option adds a step and I think the first one is probably good enough because I imagine users would understand that the feature is for signed-in users when they click and get the “Sign in” screen. I welcome any feedback though.
The source of the screen would be the single row table instead of the item table, so by default all entry components on that screen would point to that one row in that single row table.
After changing the page so it’s built on top of the new single-row sheet, the search feature works perfectly for users who aren’t signed in. Thanks @Jeff_Hager for all the help!
