[16.0] [ADD] web_concurrent_edit_global_warning

[paradoxxxzero]

This module provides a mechanism to warn users about concurrent edits from
multiple users on the same record:

It also warns if the current open record has been saved by another user and therefore is not showing up to date values:

[len-foss]

I love the module idea very much, but I have very strong doubts with regards to how it is implemented.
Could you share some insight about how you came to your solution?

[paradoxxxzero]

Thanks for your interest in this PR.

For some context this is an evolution from an other unpublished module that was based on broadcast channels to detect cross tabs concurrent edit on the same record.

It was then extended to support multiple browsers with the help of the builtin odoo websocket server.

As for the signalling implementation, it is a simple stateless synchronization mechanism. A client asks other connected clients if they are currently editing the current record and then notifies them when it starts or stops editing.

It is not meant to be perfect as false negatives are tolerable in this context (it is a warning after all) but the accent was put on implementation simplicity and performance (no server state to manage) as I had only a day or two to implement it. It is currently used in production.

Now that I said all that, please don’t be dismissive. If you have "strong doubts" please state them, if you are interested in a better signalling mechanism and have time on your hands please be my guest. I just thought it was a nice base module to share and build upon.

[len-foss]

The time you had to make the module is entirely irrelevant to whether it is a good architectural choice, so it's better left out of the discussion.

With regards to conflicting changes, in the general case that other users have a changeset in one of their tabs is a worse approximation than the write_date being more recent.
In the general case, changes can come from many different sources (external sync, portal update, ...); a widget that just checks this write_date is even simpler.

Moreover, it can be extended to be a less worse approximation -- having the list of dirty fields means we can check whether there is any actual conflicting diff.
This is still an approximation; for example, you can have a validation process that means that you can't change some fields after validation.
So even in absence of data conflict, the more recent changes conflict with your changes. Relying on a backend function means that this mechanism could easily be refined as needed through the regular inheritance.

There is however something where your approach is great, and it's social signaling.
If instead it was broadcasting 'Alice/Bob are working on this record', this is a nice way to improve the collaboration feel.

Re-stated as social signaling (real-time collaboration, etc), I would have only one big concern: AFAICT, the way it relies on in-process memory means that this wouldn't work in non-trivial deployment setups, which make more sense the more users you have. So I think this would need to be slightly rewritten to work in such cases -- even if only through an extension mechanism, with the base module stating the limitation upfront.

[paradoxxxzero]

In the general case, changes can come from many different sources (external sync, portal update, ...); a widget that just checks this write_date is even simpler.

I think you missed the main purpose of this module: warning a user that another user is editing the current record.

A concrete and real use case is when users are working on very big sale orders, the edit session can be quite long and if another user starts editing the same SO, the last user to save will override the changes of the first user silently which honnestly is quite bad.
Just checking the write_date is not enough as it would prevent data loss for the first user but not for the second who wouldn't be able to save his changes.

The purpose is to warn users as soon as possible that some data loss will happen if they continue editing.

The time you had to make the module is entirely irrelevant to whether it is a good architectural choice

Time is relevant as I would rather implement a full conflict resolution system but that does not mean this simpler solution is not useful.

[len-foss]

Ok, I see where you're coming from now, and why we're talking past each others.
You have this specific problem for this specific customer, for who this is a great solution (if not the best).
If you make different assumptions about how Odoo is used (i.e. the general case) then that solution might just be mis-aligned.
This is why my initial question was phrased this way: I suspected there was an unstated context that I was missing.

This does not really change my opinion with regards to how architecture would need to be reworked, nor does it address the technical points I've raised. As such, I'll leave it as that.

[Kev-Roche]

Tested and working, LGTM

This module effectively addresses a specific need: warning users when another user is editing the same record.

From my humble opinion:

• This module is not intended to cover all use cases: There are many modules in the OCA that target specific scenarios before potential extensions. This is an approach we regularly encounter in OCA.
• A functional first version of a module has value: Rather than rejecting an implementation that works for a real relevant use case, why not improve it iteratively? This version can serve as a solid foundation.
• Collaborative evolution: other contributors can create complementary modules or PR on the module that extend the scope.