Dealing with multiple instances of the same form

[CaseyR]

The users of the Windows version of the our program often have several views open at the same time.  They can open the same form from these different views at the same time.

The users, clever people that they are, will quickly learn that they can achieve the same multiple views in the web app by simply opening the app in a different browser tab.  The session ID is the same for the additional tabs  The trouble is if they open the same form on two different tabs, the session values for the form will be same for both. So the data changes in one form can be saved on the record of the other form even if the original records are different.

Is there a way to isolate the changes on one form from the record of the other?  Failing that, is there a way to restrict any changes to a form if another instance of the form has already been opened and not closed?
I know the terms opened and closed are not really appropriate for a web app but they matched how the user would see it.

Thanks very much.     

[Bruce]

>> Is there a way to isolate the changes on one form from the record of the other? 

nope.

>> Failing that, is there a way to restrict any changes to a form if another instance of the form has already been opened and not closed?

not really. At least not in a way that doesn't cause more pain. the problem with a form in the web browser is that the user can "cancel" it in any number of ways - by choosing another menu item, by clicking the Back button in some cases, by closing the tab in the browser, by closing the browser completely and so on.

So if you lock it for anything "except cancel" then you're gonna end up with a lot of sessions that have got locked forms, and the user will perceive this as "broken" (and rightly so).

>> The users, clever people that they are, will quickly learn that they can achieve the same multiple views in the web app by simply opening the app in a different browser tab. 

the users, clever people that they are, will also learn that this multi-tab approach is ok for different browses and forms, but not the same browse or form. (BTW, you get weird effects if you open 2 browses like this as well).

The root of the problem is simple. Session variables are "global" to the whole session. If the browser has 2 tabs open they effectively have 2 windows into the same set of variables. Change them in one window is effectively changing them in both. If you look in the web log you'll see that the browser sends no indication through of which "tab" the user is in, and hence Session variables can't be "bound" to a tab.

Cheers
Bruce

[CaseyR]

OK, multi tab is out.  Is there anyway to enforce it?   

Thanks.

[Bruce]

nope.

[Stu]

Hey Casey,

So I've "sort of" had a solution in place for a couple of months now.

Not sure if it'll fit for your situation, but sounds similar to mine.

There are two major issues I've identified.

1. A user can open multiple tabs, even multiple tabs of the same form for the exact same record.
2. Multiple users can open the same record form at the same time.

My solution kind of solves both, or at least, is a good enough hack to have significantly lowered the number of times errors happen because of these problems.

Here we go.

1. Have a memory file that has Entity Name and ID fields and a Session_ID var, as well as Username + Date/Time entered.

2. On any of the main pages (index, other major visited pages) clear the memory records for that Session.
2.a. I have a custom template attached to WebHandler that has a bunch of "procedure names" to check for, and clears on them.
2.b. Alternatively, you could _know_ the procedures that have the special logic (coming below) and anything other than them you could clear. The problem with this is that because one form could have a popup form with a child browse and another popup form etc etc.

3. For each form that I only ever want opened ONCE across any Session:
3.a. On loading of page, check if Entity Name (procedure name) and ID (if file loaded page, the id field) exist in the memory file.
3.a.1. If EXISTS, popup a little message saying "<Name> opened this page at <date/time>. Please get in touch with them etc etc." ALSO we make the form read-only (helps with general users). Also, have a custom session var here, to help with read-only any custom stuff I have in the form.
3.a.2. If NOT EXISTS, add into memory file.
3.a.2.i. On saving/cancelling of the form, the specific record added on load (because it didn't exist in the memory file) is removed from the memory file.

I think that's about it.

Has been in place for a few months, and it seems to be working okay.

Cheers,

Stu

[Bruce]

Hi Stu,

Multi-tab support was added in build 8.22, July 2014. You can read more about that here;
http://www.capesoft.com/docs/NetTalk8/NetTalkWebFunctionality.htm#MultiTab

Cheers
Bruce

[Stu]

Ha ha, yes! I was very excited about that in NT8.

Unfortunately it doesn't (or didn't, or i just didn't read up properly) help with the "multiple users opening the same record/form at the same time" thing.

But, I guess there's no harm (ha ha ha) in turning it on.

[Bruce]

same form is ok, but same record is probably not cool.... In that case you'd get a "last person wins" scenario.

cheers
Bruce

[Stu]

Not sure if I explained properly (or correctly), but that's not what my solution does.

Definitely "first person in wins".

Everyone else after that gets a blazing big popup telling them that "this other person" has the "Entity" open, and then a read-only form.

[Bruce]

yes, I understand. I meant that the default "out the box" NetTalk behavior would be Last Person Wins.

cheers
Bruce

[Stu]

Cool, thanks Bruce.