#1595 Wiki : Locking pages overwrites last author


Unlocking and locking again a locked page makes the
last entry of the history to show as done by the
current user, not by the last author, without changing
version, adding new lines, etc.

Was reported to me as happening in a 1.8.3 site, and
worked in 1.9cvs version in tikiwiki.org


  • Philippe Cloutier

    Logged In: YES

    The locking system is quite simple...maybe too much. Here's
    all there is in tiki-index.php to manage locks :

    // Check if we have to perform an action for this page
    // for example lock/unlock
    ($tiki_p_admin_wiki == 'y')
    ($user and ($tiki_p_lock == 'y') and
    ($feature_wiki_usrlock == 'y'))
    ) {
    if(isset($_REQUEST["action"])) {
    if($_REQUEST["action"]=='lock') {
    $info["flag"] = 'L';

    ($tiki_p_admin_wiki == 'y')
    ($user and ($user == $info['user']) and ($tiki_p_lock ==
    'y') and ($feature_wiki_usrlock == 'y'))
    ) {
    if(isset($_REQUEST["action"])) {
    if ($_REQUEST["action"]=='unlock') {
    $info["flag"] = 'U';

    And now function lock_page($page) {
    global $user;

    $query = "update \`tiki\_pages\` set \`flag\`=? where \`pageName\`=?";
    $result = $this->query\($query, array\( "L",$page \) \);
    if \(isset\($user\)\) \{
        $query = "update \`tiki\_pages\` set \`user\`=? where


        $result = $this->query\($query, array\( $user, $page \) \);
    return true;


    The "bug" comes from lock_page(), but as you can see from
    the conditions in unlock check ($user == $info['user']),
    there is a reason for that change.

    Managing locks would be simpler using the permission system.
    When a user locks, everyone [but admins] would lose edit
    permissions for the page but the locker, and locker would
    get tiki_p_unlock.
    There are two problems : the locker is rarely the unique
    member of a group, and also if you set edit permissions for
    others to no, you have custom permissions and you have to
    define (and update) all the other permissions.

    To sum up the problem is that $info['user'] currently has
    two uses, and the permission system has two limitations.

  • Philippe Cloutier

    • priority: 5 --> 4
    • summary: Unlocking/Locking pages overwrites last author --> Wiki : Locking pages overwrites last author
    • status: open --> open-accepted
  • Sylvie Greverend

    Logged In: YES

    I added a new entry in the history whan you look a page like
    this tha last editor name is not lost
    Chealer : you were right - but there was a solution

  • Sylvie Greverend

    • assigned_to: nobody --> sylvieg
    • status: open-accepted --> closed-accepted
  • Philippe Cloutier

    Logged In: YES

    I checked the fix and tested. Apparently, this doesn't fix
    the reported bug, but would allow to know who was the real
    last editor (by looking at the history), right?
    If that's the case, I think that's not a really good
    solution. First, I think it currently doesn't work. In 2
    tests, the locker got the version in history attributed to
    him plus the lastauthor.
    Secondly, it's complicated and I think very few people would
    be aware of how to know who really last edited the page.
    Finally, you create a dummy version of the page in history
    with a potentially confusing date.
    IMHO, I think it would be simpler to just add a field to
    tiki_pages to store the locker's ID.

  • Sylvie Greverend

    Logged In: YES

    Chealer is right. It is not a good way to fix it (the diff in
    history is bugged now)
    I cancelled my fix
    a new field or add the locker name to the flag field .... are

  • Sylvie Greverend

    • status: closed-accepted --> open-accepted

Log in to post a comment.