Optimistic locking in CRUD EDIT

[GregaUNK]

Hi,

is there any already made implementation of optimistic locking records? Do you have any suggestions how to do some kind of implementation?

Maybe thru websocket?

[karandatwani92]

Hey @GregaUNK

Backpack currently doesn't include pre-built support for Optimistic locking in CRUD.
But, the support of transactions was added recently, which you can enable by following one step

@pxpm, do you have any suggestions you could give here?

@tabacitu, what do you think of this feature? Should we add to What features should we build next?

[tabacitu]

It's a cool feature, but not needed by 99.9% of all admin panels. So I don't think it's worth prioritizing, no. We can document how to do it... but that's the length I would go to, tbh.

[GregaUNK]

Hi,

thanks, but this does not help in case, if two users want to edit the same entity at the time.

[GregaUNK]

What do you think about my approach?

I will implement Pusher through broadcasting and create a widget that will be included on CRUD edit pages. When someone tries to edit an entry, they will join the channel of the entry ID. Of course, I will also implement "leaving" from an entry, so the channel is cleared and the entry is open for editing. If anyone else tries to open the same entry, all fields will be disabled and an alert will be shown indicating that someone else is already editing it. I'll also add an override option to take over the entry and force the other person out of it.

Something like that:

<script>
Echo.join('App.<?= class_basename($entry); ?>.<?= $entry->id; ?>')
        .here((users) => {
            totalOnline = users.length;
            item_owner = 0;
            //console.log(totalOnline);
            if (totalOnline > 1) {
                users_names = '';
                users.forEach(function(user) {
                    if (user.id !== <?= \Auth::user()->id; ?>) {
                        users_names = users_names + user.name + ', ';
                    }
                });
                users_names = users_names.substring(0, users_names.length - 2);
                $('#presence_user').html(users_names);
                disable_item();
            } else {
                item_owner = 1;
            }
        })
        .joining((user) => {
            totalOnline++;
            //console.log(" JOINING:" + user.name);
        }).leaving((user) => {
            totalOnline--;
            //console.log("LEAVING:" + user.name);
            if (totalOnline == 1 && item_owner == 0) {
                window.location.href = "/admin/wait-and-redirect?redirect-to=" + window.location.pathname;
            }
        });

    Echo.private('App.<?= class_basename($entry); ?>.<?= $entry->id; ?>').listenForWhisper('takeover', (e) => {
        window.location.href = "/admin/" + '<?= strtolower(class_basename($entry)); ?>';
    });
</script>

[pxpm]

Hey @GregaUNK that's a possible approach.
Not sure about the possible pitfalls of it, since it is implemented in Javascript, wouldn't that still need some kind of checking on server side ?
I mean, If I send a POST request to the UPDATE endpoint (without going to the edit page), wouldn't it bypass that Javascript and still allow me to edit the entry ?

I would probably approach this from the server side, like having a table edit_locks, with something like: model_id, user_id, locked_until, request_for_unlock, unlock_request_user_id. If you plan to use the same thing on more entities, maybe make the table with morph columns so that it can handle different model locks.

If you want to LOCK until the owner unlocks it manually or the entry is saved and automatically unlocked, I don't think you need any JS.

You can sprinkle a simple js pooling every 10s to check for post locking requests and notify the user, if you are not already using pusher etc in your application, I think it would be overkill to add extra dependencies, 3rd party apis etc to solve some that should be "technically" simple.

Cheers