[BUDI-7085] Multiple dev collab: User has to refresh when the last user leaves the app to get design/automation access

[shogunpurple]

Checklist

• I have searched budibase discussions and github issues to check if my issue already exists

Hosting

• Cloud - qa env
  • Tenant ID: martin

Describe the bug
When a user is collaborating with another in the data section, and the user that currently has design/automation privilege leaves, the other user has to refresh to get access to design/automation.

To Reproduce
Steps to reproduce the behavior:

1. Log in with 2 accounts and access the same app
2. Leave the app with the first account
3. The other user is the only user in the "room" but needs to refresh to get the design/automation access

Expected behavior
Should update automatically through the websocket when the first user leaves the room.

Screenshots
https://jam.dev/c/39010384-1309-4dc8-a523-e5f0bbc712ab

App Export
N/A

Desktop (please complete the following information):

• OS: OSX Ventura 13.0.1
• Browser Chrome
• Version 113.0.5672.126 (Official Build) (arm64)

Additional context
Add any other context about the problem here.

_{From SyncLinear.com | BUDI-7085}

[aptkingston]

Is this a sev1? This was known and I assumed was acceptable.

[aptkingston]

I had written down in my notes that notifying a new user via the websocket would be a nice-to-have to save them refreshing, but I'll get to work on adding this if it's crucial.

[shogunpurple]

@aptkingston I believe so - I think people will probably know what to do, but it looks like a bug IMO given when someone joins the room, it's automatic. I'm just not sure why we would omit it, unless there were technical reasons to do so

[aptkingston]

We just never scoped any sort of lock transfer. I built in instant lock disconnection, removing the need the for 10 min cooldown we currently have, but then assumed that was enough, because the app list instantly reflects that no one is editing it any more. Transferring ownership of the "primary user" lock without leaving the builder again was just something I didn't prioritise.

There's no reason to omit it other than complexity but thats fine. It's using the old lock system so once the main lock disconnects, no one has the lock. So I'll just build in a race and all the other users will compete to acquire the lock and the lowest ping will win it, then hot reload their builder. I'll add new metadata for the connection time, and the next oldest session will get the lock. Everyone else will see no change.

I'll get started on that 👍

[shogunpurple]

@aptkingston you're right, it was assumed given the behaviour of users entering the room and it should probably have been specced/part of the ticket. Not a show stopper, but given the release is tomorrow I flagged it as it may trip some people up. Thanks for making the change!