How do I avoid that? I intend to have several user groups / users. Is Glideapps not suitable for this functionality?
Glide is suitable for multiple users, but to build out a custom form, you’ll want to use user specific columns…otherwise, as one user fills out the form, other users will see their entries. You want each user to have unique inputs.
I want each users inputs to be visible to the others. Since the workflow involves sequential activities and not parallel activities, simultaneous editing would be unlikely.
The problem seems to be fixed right now - I did nothing. Did the GlideTeam do something at the backend?
I suspect you will still be better off with user specific columns. Once the form is submitted and a new row is added, the data in that row should be visible to all users, unless you’re deliberately filtering it or applying row owners.
The only reason to not use user specific columns would be if you have multiple sequential users working on the same form without actually submitting. But I think that’s unlikely? (And could get horribly messy if that’s truly what is intended).
The requirement is that the input from a particular user should be visible to the user group to which that user belongs. I am using the Filter option to make that happen and am thus not using User specific columns.
However, I am not using the application such that multiple users are filing in a form simultaneously without submitting the form. The flow is a user fills and submits the form with the first set of details. Another user EDITs that same entry when a sequential activity completes and submits. I have used conditions on visibility to ensure that the sequence of activities are adhered to.
It’s me again
I always find myself coming back to this post, or others based on this.
On one hand, the concept of a Custom Form is so deeply imbedded in many of my apps. They allow the benefits/advantages you mentioned above, and so much more.
On the other hand, relying on these “New Screens” is creating a huge challenge: how to allow users to edit?
If we enable the native Edit function by Glide, we lose all the a.m. benefits. To retain these benefits, we basically need to create another New Screen. It is true that this newer New Screen will inherit fields from the data inputted based on the older (original?) New Screen, but how do we validate the new inputs/edits?
Not sure if I have explained myself well enough and also not sure if this isn’t a topic that has already been addressed. I couldn’t find anything on other posts. At least not anything directly solving this edit issue.
Would be grateful to hear your thoughts.
PS - Indirectly connected is the issue of logging these changes. I’ve addressed it in this post.
I thought you’d never ask
You may have missed this, but a while back I updated the concept app to include a custom edit screen, including an example of data validation on edit.
I live to serve
Indeed missed it, apologies…
It looks brilliant, as always.
I’m not sure I understand the interaction between the “working” and “animals” tables, while in edit status.
I’m also not sure I fully understand the need for “expired” and “all other animals”,
Thanks, much clearer now.
I just realized that this still doesn’t answer my concern. What I mean is that we still need to build two different set of (New) screen, as well as all the logic they entail. In the demo app, the logic is quite straightforward, i.e. prevent duplicate name.
The challenge is on two time points: 1. When building the screen, 2. when changing the screens, we’ll need to make sure we change on two (or more) screens.
How do we avoid this duplication? I believe we spoke about this in the past, in the sense of finding a way to “force” the app to point towards the same “New Screen” from multiple directions. That’s my idea to unify both “add” and “edit”, albeit not feasible due to inability to control the screen to which we point.
Perhaps we can use a hidden tab?
I’m not sure there is a simple solution to this. You could try and do both add/edit on a single details screen, and use visibility to hide/show things as appropriate. But I’ve never attempted that, and I can imagine it would get awfully messy. So much cleaner to keep them separate, I think. Yeah there is a bit of duplication of effort involved, but copy/paste is your friend
Hidden tabs isn’t an option. Once you hide a tab, it can’t be used - it effectively doesn’t exist.
I thought so to, so I went on putting it to the test.
As you can see in the video, we can still point towards a tab even if it’s hidden, as long as the original setting of the “go to tab” was before we hid that tab. It doesn’t show the tab name after you hide it, but it still points to it. Any ideas how can this go wrong? What are the risks?
Okay, that’s new to me. Does it work the same way in a published version of the app?
I’ll be surprised if it does.
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.
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.