Unable to edit records due to lack of lock

[darren]

Hello,

I am receiving this error when I try to edit and save a record.

"You don't have or have lost your lock on this item, it is not safe to update, please start again the edit"

I researched into the server to see if there is some sort of php error and there is no error, at least not one being sent to the error log.

When i pull up the table "dadabik_locked_records" to see what is happening I discovered that the dadabik table is not being updated, it remains empty seemingly no matter what, which I believe would lead to this error.

Not sure how to get around this error, and it started happening for unknown reasons as it worked fine before.

Ive tried restarting Apache and cheking error logs, closing people logged into the dadabik front end to no avail.

Help would be appreciated.

Enviroment:

You are using DaDaBIK version 8.1-Lerici pro, installed on 11-07-2017, the latest version of DaDaBIK is 8.1-Lerici released on 09-05-2017

You are runnning the last release of DaDaBIK

PHP Version: 7.1.11-1+ubuntu16.04.1+deb.sury.org+1

OS: Ubuntu Linux 16.04

mysql version: 5.7.20-0ubuntu0.16.04.1

Web server: Apache/2.4.18 (Ubuntu)

Client: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

 

[eugenio]

Hello,
having that table empty is ok, the error you mentioned should occurred only when you enter in edit mode and wait too long before clicking on "save"; you can, if you want, increase the time in this parameter (config.php)
$seconds_after_automatic_unlock

Best,

 

[darren]

This error happens immediately after opening a record for edit and trying to say a few seconds later.

I further tested this error and discovered it was only giving it to me while on the Chrome web browser, I tested on 3 other machines. When switching to Firefox or Edge (havent tried other browsers) the error would not happen and saving would not cause an error.

 

[darren]

For some reason the problem went away, it lasted 2 days until 5 mins before i write this post. No idea what changed, but it fixed itself somehow.

Thank You for the response.

 

[uwec]

Having the same issue when working whith multiple tabs in complex applications.

To reproduce this problem:

- open a table
- press edit for an entry
- open another table in a seperate browser tab
- edit and save an entry in the second table.
- go back to first tab and press save.

To me it seems you create a new security token(Nonce or something like that ) for every edit or create form.
When the form is send you delete the token. When working on multiple tabs the new form overwrites the old token so the still open form will no longer be functional.

I see 3 Possible soloutions to this:
1. Use self signing tokens that stay valid for this form til session times out
2. Store multiple tokens in the Session
3. Deactivate the token.

As a quick workaround 3. would be very helpfull, as this happens pretty often whith a new complex application i just made.
Maybe there is a place where the checking function can be changed to always return OK. As its just a Intranet thing , its not to dangerous..

On the long term it should be 1. or 2. as working whith only 1 Tab is not very efficient , besides the same possibly happens if you use popup windows to edit some stuff.

 

[uwec]

What really looks strange to me is the following code:

[pre]
if((empty($_GET['pre']) and ((!empty($_POST['token']) and !empty($_SESSION['token']) and $_POST['token'] != $_SESSION['token']) or empty($_POST[$_sid]) or $_POST[$_sid] != session_id() or empty($_COOKIE[$_sid]) or $_COOKIE[$_sid] != session_id())) or ($_POST[$_sid] != session_id())){
$_POST = array('enc'=>'utf-8');

[/pre]

Why the tocen code sets the Encoding ?

 

[eugenio]

Hello,
yes the situation you described makes you loose the lock on the record you are editing, you cannot work on other tables while you are editing a record.
A workaround to the problem is to reload the edit page to get the lock on the record again and THEN save.

The code you pasted is related to htmlLawed and has nothing to do with the locking feature.

Best,

 

[uwec]

Reload is not really kind of an option an Option while you collect Data from a lot of sources :-(
Is there a way to completely turn off Blocking?

 

[uwec]

Ah found it , sorry !
$enable_record_lock_feature

 

[eugenio]

Hello,
yes, you can disable the lock feature but if several people are working on the same app, it is safer to leave it enabled.

Reload should be pretty fast: you can just hit ctrl+R before editing the record.

Best,

 

[uwec]

Depending on browser already entered Changes are lost that way .
Had to press save after every change .

But that way some complex calculations and operations are triggered every time ...

What helped so far was telling the people to use the details view instead of the edit view when gathering information. By intuition they always used the first button (edit view ) and that caused most of the problems.

In complex applications still it would be great if you could edit multiple entries at once and still lock the ones you are editing.

 

[eugenio]

Ok, I understand.

A feature that is already in the todo list is adding a "edit this" button to the details page, this should help a little bit in your case.

Best,

 

[uwec]

Cool!

 

[DLJonsson]

Having the same problem with data entry on Safari Browser on a Mac.
We have long forms to complete so this is a serious problem.

Refreshing the page does not work, the form refuses to be saved after 'lost lock' alert appears.

Based on the above discussion please verify the following config settings.

Does $seconds_after_automatic_unlock --- in effect extend the timeout of the form?

What browser/s is Dadabik most intensively tested with during development?

 

[eugenio]

Hello DLJonsson,
your problem is different respect to the one reported by uwec.

In your case, setting a very high $seconds_after_automatic_unlock should fix your issue.
We are not aware of bugs about this parameter and it is NOT browser dependent.

Best,