Manila Custody Issues

Preparations for the next steps of Versioning revealed a systematic, and potentially serious, design flaw in the implementation of custody in Manila. Custody is the name of the practice of locking an entity, such as a Manila message or template, to changes from all but one user at a time. It only becomes important when an entity can be changed by more than one person, or by the same person using several tools such as multiple web browsers, or a web browser and radio userland.

In Manila Custody is implemented by 3 keys scripts

• manilaSuite.custody.checkOut - mark as entity as locked to me if possible, tell me it was done.
• manilaSuite.custody.checkIn - return an enity to unlocked state.
• manilaSuite.custody.undoCheckOut - cancel checkout, leaving entity available to others

There are many instances in Manila Suite where Manila should have checked an entity out, and checked it back in after a transaction compelted. It should also refuse to allow a tranaction to complete unless the entity is lready checked out to the user. Howver this check is rarely made.

Scenarios where this can cause problems are very common. Consider a ME who uses Radio to modify the site template. H eopens the template in Radio and then gets called away. Another Editor in the same site then uses a browser to edit thetemplate and saves his changes. The first Editor returns , makes changes to the template on his screen and transmits. The second Editor changes will be lost.