You can construct a floating back button to clear the columns as you want.
However, when I do custom forms, I just keep the inputs as long as the user has not submitted. It acts as some kind of a savable form where you can go back to other screens and go in later to continue filling the form.
One approach is to hide the back button, as Thinh described.
Another approach (and one I normally use instead) is to do your clean up on the way into the form. So if there are user specific columns that need to be cleared or set, do this as part of the action that opens the custom form screen. I like this approach better, as then you can leave the back button as it is.
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.
Hi @Darren_Murphy,
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.
Thanks
PS - Indirectly connected is the issue of logging these changes. I’ve addressed it in this post.
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?
