How to notify object changes - best practices

0
Hi Everyone  We have observed one issue and we like to have pointers to solve the same. Issue description: user 1 opened a page where certain activities can be performed. But page has opened and kept idle. Mean while user 2 opened the same page and did the actions exactly opposite to those actions which user1 intended to do. Now since user1 kept the page open, user 1 did his activities which has over riden user 2 activities.   Now we want to prevent this. When any user is trying for any activity, system should check and notify whether the state of the object has been changed.   Pls provide some pointers
asked
3 answers
1

It sounds like only one person should be editing this data, so one approach would be to add a lock to the page.

 

You could do this by having an entity you retrieve a single instance of, and have a boolean locked attribute in there. When a user tries to open this page via a microfow, retrieve this object and check the locked attribute. If it's true, then return an error message saying the page is in use. If it's false, then set it to true and commit, then open the page. 

 

When the user with the open page saves their data and closes the page, retrieve the object and set the locked attribute to false. This will free it up again for editing.

 

If you are worried about someone keeping the page open, you could add a microflow timer to the page to release the locked attribute and close the page after a certain time.

 

I hope this has helped.

answered
1

You could also use the changedDate.

 

When calling the MF to save the object you could:

- Retrieve the object from the database ($Object = id)

- Check the changedDate from the object in memory against the one retreived from the database.

- If they are not equal you could abort the save MF and show a message. (Object changed, refresh/re-open this page)

 

Disadvantage is that this checks after the user tries to save.

answered
1

Locking and checking dates is one option.

  • But the counter arguments about user closing browser or navigating away from the screen cannot be very well handled.
  • Handling, browser close and user clicking another button or link is difficult to trace. Ofcourse we can think about un-mounting events of a widget etc, which did not worked very well in my experience. 

 

Rather, I would try versioning of the records.

User 1 - creates the data - Version 1

User 2 - Opens the data - Version 1

User 3 - Opens the data - Version 1

User 2 - Saves the data - Version 2

User 3 - Saves the data - Obviously the version loaded was in memory and not updated. So, we can always check if the version loaded in memory and version in DB to decide about persisting. 

 

There are other suggestions as well about checking changedDate.

answered