Hi,

When editing a view I get the message "This view is being edited by user admin, and is therefore locked from editing by others. This lock is 1 hour 20 min old. Click here to break this lock." - However I am logged in as user "admin".

Then I have to break the lock and lose the changes I made to the view.

Has anyone else experienced this problem? Normally this occurs when I edit a view, forget to save the changes then the next day or after a few hours, when I try to edit the view, I see the message even though I am using the user account referred to in the message.

Thanks in advance for any help on this issue.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

VM’s picture

Category: bug » support
Status: Active » Postponed (maintainer needs more info)

when you break the lock the changes aren't saved from the previous session. Evidentally you closed your browser and started a new session?

h3000’s picture

yes - when I break the lock, the changes I made are lost. In cases where I edit the view the next day, usually, the browser is closed or I am using a different computer. - but like for this one, message says the lock is 1 hour old - I did not close the browser - the message just came up.

VM’s picture

did you start the edit in a different browser? or a different window?

h3000’s picture

In this case no - same browser, same window - I started making changes to the view, then did something else (had some lunch) - then when I started editing the view again, the message came up

VM’s picture

not sure it's a bug but I'll let merlin comment.

I've never seen the lock message come up while i was working in a view. Personally, I don't walk away form my machine when in middle of a view, I hit save first.

To me this would seem by design.

h3000’s picture

I think I was editing the view, changes I made did not result into the view that I wanted so I usually just step back and do something else first and come back at a later time.

Normally if the timeframe is just a few hours like 1-2 hours, I don't get the message - it usually happens if I edit the view on the next day. Could it be related to sessions being renewed?

But still, if I use the same user account, the message should not appear right? or at least there should be an option for the user to keep the changes or see the current (unsaved) changes to the view.

merlinofchaos’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Indeed, the lock is tied to session. If something happened to cause you to have a new session (being logged out and logged back in again, for example) then your changes will be lost. This is by design.

ari-meetai’s picture

I'm also experiencing this. Now I understand the cause. Would be better to simply break the lock if you're the same user (admin) than the lock's as no further real functionality is offered.

ari-meetai’s picture

Category: support » feature

Marking as a feature request.

VM’s picture

Category: feature » support

remarking as a support request as I don't see where there is a request for a feature involved here.

The lock is the feature. Those who close their browsers or allow their session lifetime to expire have to break the lock to make changes.

h3000’s picture

It just seems to be confusing to have to break my own lock. Probably the message has to be changed?

VM’s picture

suggestions for what the message should be changed to? Keeping in mind that if you aren't the only person allowed to administer views it may not be your own lock.

merlinofchaos’s picture

It's also intentional that if you're using a different browser and therefore have a different session ID, the locks are separate.

cybermache’s picture

Version: 6.x-2.6 » 6.x-3.x-dev
Status: Closed (works as designed) » Needs review

IMHO, if this is not a locking system that has anything to do with who is logged in, then the language is confusing and misleading

This view is being edited by user '%username', and is therefore locked from editing by others. This lock is '%session' old. Click here to break this lock.

If we accept the current views design for locks then the phrase "is being edited" is completely misleading. To say it 'is being' suggests that this user will log in again, pick up where they left off and this warning is to other users to not delete their work. Which is confirmed with the last part of this sentence "locked from editing by others". If this locking feature is not going to be changed then I suggest this message say something like the following.

This view's editing session by user '%username' has expired, and therefore is locked from editing. This lock is '%session' old. Click here to break this lock.

If there is protocol to avoid views locking then this would be a good place to add it. Again just MHO.

merlinofchaos’s picture

Status: Needs review » Closed (works as designed)

There is one problem.

There is no way for Views to know that the session has expired. If it's printing that message, there is a session record in the database. If there is a session record, then the user could, at some point, come back to it, from the perspective of Drupal. It has no way to know if the browser has closed and lost/cleared the cookie or if you're simply the same user on a different browser.

Also, 'needs review' is reserved for issues with patches.

cybermache’s picture

Well I still think this message is misleading and the cause for many Drupal users to post issues just like the one we are commenting on. My main point is that maybe by changing the text in question we might eliminate unneeded and unwanted inquiries into Views Locks. By seeing your comments on other posts that have invoked your involvement I thought you might be for this benefit. That's why I changed the status to 'needs review' which I guess isn't as descriptive as it seems (and might be in need of review itself [wink] ). So I won't change the status anymore I just didn't want this to disappear because I thought people will continue to find the Views Lock message confusing.

As for my suggested solution, I wasn't suggesting that Views did know a session had expired, it was just a suggested change in the phrase. You know a step in a new, possibly more descriptive direction? Well take that for what it's worth.

I agree with the problem you bring up. Can you confirm my assumption that this is, for lack of a better term, an umbrella situation. Where the issue of expired cookies or different browsers is "slipping through the cracks" of what this function is purposefully designed for?. Also can all readers interpret your phrase "from the perspective of Drupal" as meaning that there isn't actually a way of returning to the view's edit session without breaking the lock, even if you are the same user the lock was made for.

merlinofchaos’s picture

That's why I changed the status to 'needs review' which I guess isn't as descriptive as it seems (and might be in need of review itself [wink]

I complain to the powers that be about that regularly.

Also can all readers interpret your phrase "from the perspective of Drupal" as meaning that there isn't actually a way of returning to the view's edit session without breaking the lock, even if you are the same user the lock was made for.

That's correct. The locks are tied to sessions and sessions are tied to browser cookies. If you don't have that cookie, you can't get back to that session. But there's no way for Drupal to know that you don't have that cookie anymore.

When a session is truly expired, i.e, removed from the database, I believe the lock is invalidated automatically, since Drupal does know that without an attached session, the temporary data is now garbage. It is, however, intended to be that a single user can have separate locks if, for example, using multiple browsers.

higherform’s picture

Also ran into this issue in the 6.x-2.x branch.

My suggestion would be to add a second option besides just "break the lock" and lose the changes. The second option should be "resume editing". Perhaps this would only be offered when the uid of locking user == uid of current user. The unsaved changes would then be updated to be owned by the current uid/session information, and the edits could be completed and saved normally.

This would be useful in the case a user hit "Save" but somehow the save operation does not complete, which has happened to us in development in the past.

jason.fisher’s picture

Agree with the request for the ability to resume editing a 'lost' session.

ExTexan’s picture

Same issue in D7 (obviously).

I was editing a view with 4 displays. I had made several changes to 2 of them and decided to save my work. I got Access Denied, as Drupal had logged me out (for whatever reason). I got the locked by admin message when I logged back in (as admin). In my case there was no time lag (i.e. no lunch break).

I'd like to +1 the "resume" option request.

perelman.yuval’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Issue summary: View changes
Status: Closed (works as designed) » Needs review
FileSize
4.24 KB

Hi all.
I create an patch that add an "Resume editing" link to the views edit page, if the current user is the same user that create the lock.

Status: Needs review » Needs work

The last submitted patch, 22: views-resume-edit-locked-view-535256-22.patch, failed testing.

perelman.yuval’s picture

fix the whitespace

perelman.yuval’s picture

perelman.yuval’s picture

Status: Needs work » Needs review
raxxraxx’s picture

This is still needed. It would be great to simply be able to resume editing a previously edited view (with the same user, of course.) With much development happening on multiple devices and in multiple locations it would be very useful to be able to pick up where you left off no matter which device you're using.

raxxraxx’s picture

Category: Support request » Feature request
vrwired’s picture

#24 patch worked for me and saved a couple hours of nearly lost figuration ... had to clear cache but able to access 'resume edit' after that... thanks!

Honza Pobořil’s picture

Resume page is empty and this messiges was shown:

Notice: Undefined index: views_ui_resume_edit_confirm in drupal_retrieve_form() (line 807 of /var/www/drupal/includes/form.inc).
Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'views_ui_resume_edit_confirm' not found or invalid function name in drupal_retrieve_form() (line 842 of /var/www/drupal/includes/form.inc).

Views 7.x-3.20

Chris Matthews’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

The 5 year old patch in #34 to admin.inc and views_ui.module does not apply to the latest views 7.x-3.x-dev.

Checking patch includes/admin.inc...
error: while searching for:
}

/**
 * Helper function to return the used display_id for the edit page
 *
 * This function handles access to the display.

error: patch failed: includes/admin.inc:879
error: includes/admin.inc: patch does not apply

Checking patch views_ui.module...
Hunk #1 succeeded at 126 (offset 22 lines).
Hunk #2 succeeded at 940 (offset 64 lines).
DamienMcKenna’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
4.1 KB

Rerolled. The code could use a slight tidying up to match the Drupal coding standards but I'll leave that for someone else.