CLARIAH / pure3dx

pure3d: the bare app
MIT License
0 stars 0 forks source link

Prevent edit conflicts #5

Open dirkroorda opened 1 year ago

dirkroorda commented 1 year ago

When users modify material, they may destroy each other's data inadvertently, and that should be prevented.

We deal with that in several ways:

When a user presses an edit button but an other user is already editing that field, instead of presenting the field in edit mode, the nickname of the user who is editing the field is being shown.

There might be cases where the other user's system did not detect the end of the edit session. In that case we need something to overcome that.

For example: edit sessions always terminate within 10 minutes after the last keypress.

We could show that users are typing (like you see in Whatsapp and Slack). Editors and sub-editors could send a message to the one that is typing with a request to save.

If we need this kind of communication we could use Flsak-SocketIO.

dirkroorda commented 1 year ago

It is important to have a quick, albeit coarse solution.

Only one person can have a voyager story session for an edition open at the same time. During that time, no edition related modification can be made, not even in logo's and metadata. Also, role assignments to people cannot happen then.

For projects the same holds: only one person can modify project details at the same time, including the manager role.

dirkroorda commented 1 year ago

In more technical terms:

In order to modify something in a project, you need to obtain a project session.

In order to modify something in an edition, you need to obtain an edition session.

Only if you obtain the appropriate session, you can modify things.

In order to modify edition-level things, you do not need a project lock.

In order to change assignments of user roles for projects / editions, you also need to obtain a project / edition session.

No two users can have a session for the same project /edition at the same time.

A user may obtain the same session at the same time in different browser windows and then run the risk of overwriting himself. (Or should we guard the user against this?)