Best way to allow users to edit shared "configs"?

Using Django
1

I am working on a feature for an application of mine that allows users to edit certain configurations that is stored in a database. These configurations are shared and not unique to one user, but obviously only a select few would have permission to edit it.
Using a TemplateView the client can view this data that gets nicely populated into a DataTable with inline editing that updates live as the user edits it. Issue I am now experiencing is as follows, if two or more users are logged in and trying to edit this config at the same time there is a clash between what the two are seeing. One could have edited row 2 while the other has edited row 10 and not know about 2 being changed unless they refresh the page. Worse, they could both be editing the same line and not know it. Is there a built in method to “lock” editing to one user at a time? I looked into select_for_update() but I don’t think this is the correct solution.

Any tips or best practices are welcomed since I am struggling to figure the best way of doing it. Currently I am just using another table to keep track of when someone starts an edit “session” and block the other user from being able to do anything till the one is done but what if that user closes the browser without exiting the session. It blocks the other user then.

2

No, there’s no built in way to do this AFAIK.

The way you’ve suggested (“locking”) is a common way for wikis to work and is a tried-and-tested approach. There is often a timeout on wikis. Another way you can do this is to use a timestamp or revision number:

  1. Both person A and B are sent the same HTML, with timestamp 2pm or e.g. revision 1 (stored on the model)
  2. A submits the form
  3. Your app checks that the submitted form has the same timestamp/revision as the db. In this case it does, so the update is made and the new timestamp/revision saved.
  4. Person B submits the form
  5. Your app checks, but the revision in the db is now 2 and they were editing 1. So you return to the user and say ‘sorry the underlying data changed, please do your thing again’.
3

It sounds so simple to implement it like that but surely it has its drawbacks correct? But I will work on what you have suggested. This isn’t something I have ever needed to do before and I don’t want to do it in a way that would be considered bad practice.