Announcements
The Google Cloud Community will be in read-only from July 16 - July 22 as we migrate to a new platform; refer to this community post for more details.

Suggestions to prevent more than one user modifying the same row

Hi everyone,

In my app, we have a feature to start an inspection. The user needs to click on a action button that takes them to a form. When the form is saved, an action is also performed to save the timestamp of the event. Once the inspection is started, the action button to start an inspections gets removed to prevent other users starting the same inspection

However, there is an edge case when both users haven't sync and both start filling up the form at the same time, this causes some unwanted issues. The way that I'm trying to solve this is doing the following:

1. Triggering a force sync when navigating to the form, as shown by @MultiTech in this video: https://www.youtube.com/watch?v=3BQ_xVnalm4 Thanks for that! 

By syncing before filling the form, the user should have the latest data

2. Checking that the timestamp is null when saving the form. This will prevent that the second user  (after the first one already started)  saves the form because the timestamp value has already been synced (thanks to the forced sync from the step before)

The issue is that in the validation of the form (I'm using Valid If); I'm checking for an empty timestamp, but because the timestamp gets set after saving the form in the 'Form Saved' event, the saving forms and gives an error, because the timestamp is just getting updated by the same form

How can I check for the timestamp field before getting the form saved but also allowing the form to be saved and not mess up the first time that the form gets saved?

Thanks

0 13 338
13 REPLIES 13

Hello, u need two step

first, you save timestamp if is empty and then you go to your form

Thanks for the suggestion, but there is the edge case that if the users hits Cancel in the form, then the inspection shouldn't start. And if I set the time beforehand, then I won't be able to easily unclear that value

you're right, for the unclear. how long your inspection last ? maybe u can manage a session duration and the your test is timestamp is empty or up to data

Inspections can take seconds or days, it all depends on the user. I will try what @AleksiAlkio  suggested

Add a condition to your Valid_If that it only checks it when you are using the form view. The action should not use it and it pass the validation.. I believe.

That sounds like an interesting idea. I'll try first with the 'Edit if' the timestamp is blank, if that doesn't work, will try your suggestion

Unfortunately, that didn't work, still applies the check

What formula did you use? 

In the Validation for a field in the form I used something like:

if (Context("View") = name of view) check if starttime is blank, otherwise, do not check.

I also tried with ViewType = Form

May I ask what was the formula exactly.

IF(Context("View") = <NAME_OF_VIEW>,

ISBLANK([stardatetime]),

True)


@andresjgc wrote:

1. Triggering a force sync when navigating to the form, as shown by @MultiTech in this video: https://www.youtube.com/watch?v=3BQ_xVnalm4 Thanks for that! 


Cheers!

I'll be honest with you: 

  • You'll be better served NOT going down this road.  (Trust me)

The problem you're facing is one of "multiple users editing the same row" - and the solution to this, is to NOT do this. ๐Ÿ˜‚

  • Instead modify your data structure so that each user is creating/editing their OWN record; then on a parent level, create a system that chooses which one of these records to use.

Going this route even gives you the possibility of creating a bot that checks for a previous record.  Since bots execute from the server's perspective, it should have the most recent data - including the first user's record.  

  • So you can setup a bot that looks for if there is something already present inside the [Related Whatevers], and if there is... it rejects the 2nd record, possibly sending an email to the records creator letting them know that their submission is in error.

____________________________________________________________________

It will require some reworking of things, but ultimately this is the route you'll need to go if you're expecting this to work in a smooth way. ๐Ÿ‘

Hope it helps. 

Hi MultiTech,

Thanks for your recommendation. That is definitely different to what I had in mind. I'll consider this route, it will require some changes as you mentioned but I think it will be worth it.

What are some reason why I shouldn't take the force sync route besides adding that sync time? Is there any other considerations ? 

 

Thanks

 

Top Labels in this Space