Product Development

Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 118 rates

Implemented in 4.4

Page locking alerts you if someone else is already editing a page you wish to edit.
See MGNLSLOCK-1@jira (was formerly MAGNOLIA-88@jira)

Soft Locking module provides concurrent editing capabilities.

Official Documentation Available

This topic is now covered in Soft Locking module.

Problems

  • Magnolia has no explicit moment when you enter or leave the edit mode

Potential Solution

  • We should not use jcr locking but a soft locks
  • We could to use the preview button to toggle locking or unlocking
  • The pages are always opened in preview mode and pressing the edit button toggles to edit mode (lock).
  • The page polls then (by using ajax requests) and as soon no request reaches the server the the page is unlocked (no user action)
  • If a page is locked you still see the edit button but with a warning. If a user wants to he can none the less enter the edit mode.

Variations

A) lock only if you open a dialog

Scenarios

  • user A edits page x
  • user B edits page x
    • user B gets a warning about A editing the same page
    • does user A get a warning about B editing the same page?
  • user A is done with editing and saves page x
    • does user B gets a warning about A having savd the page?
  • user A clicks on preview
    • does user B gets a message about A releasing the lock?

Questions

  • No labels

6 Comments

  1. Boris Kraft

    Why not simply wait until someone clicks "edit"? You cannot edit a page without opening a dialog first. Of course be aware that we sometimes want to open more than one edit dialog on a page.

    1. Philipp Bracher [old account - now Philipp Bärfuss]

      I think it is a bit more transparent if you enter the edit mode explicitly. It is also nicer if you see the green bars only if you need them. But sure this is an option.

  2. Boris Kraft

    I try to minimize clicks. If we open pages in preview mode instead of edit mode, this means one more click before being able to edit. It would change the behavior we had for the last 5 years with no apparent benefit. Also, what if one navigates away from the page? Will every visited page automatically be locked? Or every other page will be in preview mode as well? This would quickly be very confusing, I think.

    But making it explicit might still be an option. For instance, one could add a button to the main bar to explicitly lock the page. I don't like it much but it would be explicit.

    I would prefer it if it normally is transparent. An editor should not need to care. Only if I want to edit a page that is already being edited should I get an alert.

  3. Françoise Gérard

    I used OpenCms on another project, their way of locking was interresting:

    • a user right click on a node and selects 'lock' ; this puts a lock on the node and from that moment only that user can modify it
    • other users sees the status is changed (we can imagine a new color status for Magnolia) and see who is locking the resource (with mouseover the statu)
    • the user locking the resource can even save it (what releases the lock), even unlock the resource manually
    • a superuser can steal the lock of someone else (overriding the modifications of that someone else)

    What was nice with this method is that you clearly now that the resource is being edited by someone else, and if you have to modify it also you can give that person a phone call (for example).

    There is no surprise modifying a page and seeing that the content is not what you saved!

  4. Vivian Steller

    Just my 2cts: regarding usability...

    • first and foremost: locking is a must. Nothing is more annoying/confusing for a user as magically loosing changes that took him time to affort or if the result isn't what he expected. In usability terms this has to do with expectation conformance, failure tolerance and the general goal of user satisfaction/"joy-of-use" - simply "avoid frustration".
    • next: avoid explicit locking (e.g. by clicking a "lock this page" button): optimally, the user shouldn't have to be aware of the fact that he is working in a distributed environment. For him it should look as if he is working with a local document (well, this is the goal at least). Thus make locking transparent. This is again expectation conformance.

    With these things in mind I would vote for a more pessimistic, but implicit locking approach. By implicit locking I mean, lock only if someone really edits a page. However, consider that editing not necessarily means hitting some edit button. Editing might also be trigged (in future releases) if someone simply moves a paragraph just by drag'n'drop.

    By the way, what about locking on a paragraph level?

    Technically I think there is no other way to check periodically via AJAX requests if someone else edits a page/paragraph, which applies to both Admin Central and Preview mode. Admin Central because of the use case that someone shouldn't be able to move/rename a page that is currently being edited....

  5. Vivian Steller

    And yes:

    • we should really indicate visually that a page/paragraph is locked, again in both AdminCentral and in preview/editing mode. This is once again expectation conformance. The user shouldn't have to click and try to edit to see that he actually can't at the moment.

    And allow me one more hint regarding this visualization: please don't use the "lock" icon for this. This is reserved (wink) ...for the case of "restricted" pages / the case that someone hasn't write or even read access on a page. Instead use the "disabled"/"greyed out" style for the page name and the edit button. Thanks (wink)