How to lock articles against concurrent multi-user editing?

[svenf]

Hi all,

i did not found a feature/plugin, that handles concurrent write access at the same time and the same article/post. How to notify a second author, that the article he wants to edit is already accessed by another author?

Thanks + kind regards
Sven

[garvinhicking]

Hi!

Sadly this is a general weakness of online CMSes. As you have already seen, s9y doesn't provide a real method for that.

However, adding a plugin that acts as a notifies should be easy. It could work like this:

1. When an editor edits an article (backend_entryform hook), a "write lock" is created (in a seperate table, or maybe even using the serendipity_Entryproperties table).

2. When the next editor edits an article, a message is shown that tells him "Editor B is editing this entry! You cannot save the entry until he has either released the lock or it has time-outed."

3. When Editor A saves the entry, the write-lock is released and he is telported to the admin edit interface (usually you would be back at editing the entry, but that would then re-enable the edit lock which should not be done)

4. When Editor A does not save the entry, a lock would be erased after X minutes automatically. Plus a button "Release Lock" could be shown in the interface.

Is that something you practiaccy need? Because very often, the wish for this might arise, but it is very rarely used in real-life environments, and thus it is often not really required.

Best regards,
Garvin

[svenf]

Hi Garvin,

thanx for fast response!
This is exactly i would like to see.
Currently i'm playing around with S9Y as team collaboration and news propagation platform for a bigger team. We plan to announce bugs, software features, meeting minutes etc. by using S9Y. Different authors should be able to edit/review the same article with no risk to overwrite other's work.
Your solution sounds very acceptable.

Thanks +kind regards
Sven

[svenf]

For the first draft it could work in that way:

* a plugin creates a new table with two columns: article_id and author_id (or author_name, what is cheaper in terms of SQL queries?)
* when entering the edit mode of a article the table is queried:
- if entry exists a warning "article is locked by ..." is shown (and the "save" button is disabled)
- if entry not exists a row is inserted

* when leaving the edit mode (can this event be captured?) the article is unlocked (that means the table row is deleted)
* with a "unlock" button the article can be unlocked by everyone (the responsibility for consistent content is delegated to the authors) (that means the table row is deleted)
* a timeout is not required because everyone can unlock the article (after consulting co-authors, hopefully)

a minimal version could have a "lock" and a "unlock" button only for manually locking/unlocking, so the enter/leave edit mode events do not have to be captured.


Kind regards
Sven

[garvinhicking]

Hi!

You could use the serendipity_entryproperties table for storing the associations, I think. That's the best way and easiest retrievable.

Do you maybe have some willing PHP guys in your team that would want to help flesh out the plugin? I could throw some rough drafts into your directions, if you need the plugin fast?

Best regards,
Garvin

[svenf]

Hi,

we are all new to PHP, so i guess i will not find supporting guys in my team
Currently the blog is not yet in production, so there is no time pressure.
A first beta version within the next 60 days would be great ....


Thanks a lot
Sven

[garvinhicking]

Hi!

I just added basic locking support to the "Rules of Publishing" (serendipity_event_entrycheck) plugin. It will automatically lock an article when entering the edit mode, and a lock is removed after 1 hour of inactivity. There is no "leave" event in HTML environments, so we can't do that.

I also added an "unlock" button which will steal a lock and let you be able to edit an entry.

You can find the updated plugin here: http://php-blog.cvs.sourceforge.net/php ... entrycheck

(you need to download all the files there - you can also grab the ZIP or via Spartacus, but that might take upt o 48 hours until its available there)

Best regards,
Garvin

[judebert]

And the database does these steps atomically, right? So there's no race condition, where A retrieves the lock status, B retrieves the lock status, A sets the lock, then B sets it too...

I don't know what that SQL would look like, but it would be necessary in an environment with lots of concurrent users.