You’re right, dead on published
OK, maybe not DOP.
I moved the hidden tab to the Menu section, and now it works also on published.
I also added another action in the custom action sequence. This seems to keep the button alive once the tab goes to hiding.
Thoughts?
Update:
I took @Darren_Murphy’s advise and tweaked the logic behind the hidden tab.
Here’s the demo app again
Here’s what I did:
- In the Users table, added a Boolean column for “ShownHidden”.
- Tab isn’t hidden. Instead, visibility parameter is to show only when “ShowHidden” is true.
- When a user clicks on the text button, first action is to set this Boolean to TRUE. Second action is to go to the hidden tab. The tab is nested under the Menu, so technically it would be very difficult for a user to see it outside of clicking this button.
- When finished editing, first action on the button is to set “ShowHidden” to FALSE.
This works. It requires to log into the app, but that’s OK anyway as my apps are always private and login is enforced. I assume we can further tweak it to work when not logged in.
Thoughts? Problems? Challenges?
Remind me again what problem this solves?
Is the purpose of this to avoid a “Show New Screen”, or…?
This allows us to point towards the same exact screen from multiple directions. One usecase is to use the same screen for both add and edit. I’m sure we’ll find many other usecases for this 
:
Where are the problems/drawbacks/disadvantages? I’m sure there are many of those…
Okay, well let’s consider the case of editing a record.
When you want to edit a record using a custom form, and you’re not doing it on the current details screen, you need to ensure two things:
- The screen you navigate to is attached to the table that contains the record that you want to edit, and
- The screen that you navigate to is also attached to the correct row in the above table
(or, I suppose 3. you create appropriate relations to connect you to the table/row that you want to edit)
So if you’re going to navigate to another tab, how would you propose to ensure those conditions are met? It will be possible, but it won’t be simple.
Conversely, if you simply do a Show New Screen → This Item, then you automatically land where you need to be.
So it seems to me that the path you’re heading down is adding unnecessary complexity and creating extra work.
In our usecase, this hidden tab is pointing towards the working table for Animals, allowing us to both add and edit animals.
Let’s look at this as if we’re sending data to an extremal service (Make scenario for example). Each time we send to this scenario, we make sure we provide it with the proper variables. We’ll do the same here using the “set column values” in this working table. We can add a column to indicate the “mode” in which we approach this screen, i.e. “add”, “edit”, etc.
We have zero control over where we land and we also must make sure we always come from the same item.
Another upside I can see here is that we get a clear list of our screens (i.e. tabs) and we can edit them at will. Using the New Screen doesn’t build us a clear list of screens that we can edit outside of the direct connection to the item from which we originated. Such as list is very much available on other services such as Google’s own AppSheet.
True on the one hand. On the other hand, we eradicate 100% of the chances we’ll miss something during the duplication of complex screens.
I see this as a change of perspective. Instead of a single dimensional screen (serving 1-2 purposes) we get a multidimensional screen.
Important to say that this workload is worth it only for super complex screens, such as adding a new client, new SKU, etc. Basically, in cases where the data integrity is critical. In these cases, we want to make sure we always follow the same exact logic when entering new data into the system. Narrowing it down. with this screen we can configure one Save button, as opposed to a dedicated Save button on each New Screen originating from the same item. This unified Save button will always check the same logic, before allowing itself to be visible/clickable.
Adding is fine, because you can add a row to any table from anywhere. But editing is different, you need to be attached to the correct table and pointed at the correct row. So are you suggesting that when the user saves an edit, you’ll do a set column values via a single relation back to the Animals table, so that the correct row is updated? Whilst that could work, again I just see it as making things more complicated than they need to be.
If it’s in the Menu, then it’s easy enough to find. What would the behaviour be if a user navigated to it directly?
What do you mean? Of course you do. Show New Screen → This Item just opens a new screen on the current row. So you always know exactly where you are. You do realise that when you apply an action to a details screen, then it automatically applies to all items that share that same details screen, yes?
I’m far from convinced. But maybe I’m missing something. Show me a fully functional example.
1 Like
User cannot navigate to this tab, or even see it. It’s not visable unless the ShowHidden Boolean is true. That only happens when we want it to happen (and we also remove the back button via CSS).
Not sure I understand what you mean.
To be honest, I’m taking this approach purely due to my past experience. That was on other platforms, but I do know that somewhere, somehow, I’ll miss something if I need to duplicate things. That’s just me. I’d like to assume that most of you guys don’t have this “wonderful” experience.
It’s probably just me trying to convince myself, but I do believe that the easier mindset is one screen to consolidate all additions and changes to one table.
I have tried similar logic to avoid duplicate entries when they are entered. But the app only works for a single user. If multiple users write at the same time, it mess up the data completely. How can we avoid this?
Did you see my response to your question in the other thread you created?
1 Like
Its working, thanks!
Hello.
As the other participants of this conversation, I tried to validate items being added or edited, to prevent duplicate items.
The solution looks great, but I didn’t succeed to use it, because in my data table, the data is updated only after pressing the submit button. Before pressing the button, nothing is written in the data table.
Do you know what is my mistake?
Thanks a lot!
If you are using a custom form, then you are updating a data row as you type, so it may be the case that you are not using a custom form and you are instead using a native Glide form…or your logic to check for duplicates is in the wrong table.
2 Likes
I succeeded. Thanks a lot!
3 Likes
Thanks
This is very useful, but i cannot seem to find out how to make location a required field in the new version of Glide. Any ideas?
Do you mean getting the actual location of the user using the custom form? You can write that location to a column in the custom form, and only allow submission if that column is not empty.
1 Like
@Darren_Murphy thanks for redirecting me here! I am looking at the app you made to understand how to avoid duplicates but I am not getting how to apply this to my app… also the ACTIONS are not available on your app, I don’t know why so I can’t see actually what the actions are doing.
I was wondering if you have a post or video showing how you made this app so I can see the steps you did to accomplish this cool feature
Thanks!
AA
@Pnina_Barth can I bother you detailing me how you accomplished it? I am on the same path but I am struggling to understand the logic and steps to validate when adding an item so avoiding duplicates. Thanks!
It’s a very old Classic App, which didn’t have a separate Actions editor.
Glide has changed a lot since this was made, although the general concepts are the same.
Making a more modern version is on my todo list.