Case 1: User surfs View -> Edit (without changes) -> View ---- and the node is reported to be locked and the user would need to unlock it manually. This surprises me, because going back to View IMO should release the lock.

Case 2: In Checkout, content got locked when people surfed to Navigation or Revisions. Now, while locking because of simply viewing Revisions is filed as bug here (tends to lock too often/unintentionally), the new module content_lock doesn't lock for Navigation and Revisions to the extent that a content reported as locked can be changed in the navigation, or be reverted to an old revision. I'm not sure that's wanted.

I've have had my frustrations with Checkout so I'm hopeful that content_lock will work better :)

Comments

eugenmayer’s picture

eugenmayer commented

case1:
Its important to read the "goals" of the module. There you find this

The main goal is to be 100% safe. That means that in no case a user should be able to edit a node, which is currently edited. Its rather chosen to be more user-unfriendly then removing the edit lock to early. In example the user can only remove that lock using save or the cancel button. Moving backwards in the browser or closing the browser does not yet unlock the node. Therefore the user will be notified and he can use a simple link to unlock the node (if he wishes too).

Thats most probably the whole answer you need.
-> Node gets locked when you enter "edit"
-> Node gets _only_ unlocked when you press save ( and the nodeapi is called ) OR you have a cancel button which is also unlocking during its process.

That Cancel-Button is missing in Drupal generally and i have introduced it in my installation by alter. I will include this "cancel" button as submodule here, as i guess this is pretty critical. I also have tuned the "View" button in my Drupal installation to work as "cancel" (thats what it actually does..) (the local task view) BUT that is not the same with:

-> Navigating to the node in a different tab (never unlocked)
-> doing _any_ navigation on the page.

So to summarize, to remove the lock, you have to start a valid transaction to unlock it:
1. Save
2. Cancel (View)

There is a new optional (in development) unlock way using JS and the "on leave" event .. where the user gets asked if he really wants to leave that edit page (or close the window). If that is confirmed, unlocking is done using ajax.

2. Case
Why should there be a lock _viewing_ revisions? I cant see any sense in that and i guess i most probably misunderstood this point here.
The valid point i can see here is that case:
A user A edits the node.
A user B comes arround and wants to revert that node. While that is critical in the logic way anyway, the proper solution in that case is:
-> UserB cannone revert or more generally do any _state modifiing_ things on the node. So he/she will be forced to wait for the node to be unlocked.

eugenmayer’s picture

eugenmayer commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.