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.
Comment | File | Size | Author |
---|---|---|---|
#32 | views-n535256-32.patch | 4.1 KB | DamienMcKenna |
| |||
#24 | views-resume-edit-locked-view-535256-23.patch | 4.14 KB | perelman.yuval |
Comments
Comment #1
VM CreditAttribution: VM commentedwhen you break the lock the changes aren't saved from the previous session. Evidentally you closed your browser and started a new session?
Comment #2
h3000 CreditAttribution: h3000 commentedyes - 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.
Comment #3
VM CreditAttribution: VM commenteddid you start the edit in a different browser? or a different window?
Comment #4
h3000 CreditAttribution: h3000 commentedIn 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
Comment #5
VM CreditAttribution: VM commentednot 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.
Comment #6
h3000 CreditAttribution: h3000 commentedI 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.
Comment #7
merlinofchaos CreditAttribution: merlinofchaos commentedIndeed, 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.
Comment #8
ari-meetai CreditAttribution: ari-meetai commentedI'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.
Comment #9
ari-meetai CreditAttribution: ari-meetai commentedMarking as a feature request.
Comment #10
VM CreditAttribution: VM commentedremarking 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.
Comment #11
h3000 CreditAttribution: h3000 commentedIt just seems to be confusing to have to break my own lock. Probably the message has to be changed?
Comment #12
VM CreditAttribution: VM commentedsuggestions 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.
Comment #13
merlinofchaos CreditAttribution: merlinofchaos commentedIt's also intentional that if you're using a different browser and therefore have a different session ID, the locks are separate.
Comment #14
cybermache CreditAttribution: cybermache commentedIMHO, if this is not a locking system that has anything to do with who is logged in, then the language is confusing and misleading
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.
If there is protocol to avoid views locking then this would be a good place to add it. Again just MHO.
Comment #15
merlinofchaos CreditAttribution: merlinofchaos commentedThere 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.
Comment #16
cybermache CreditAttribution: cybermache commentedWell 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.
Comment #17
merlinofchaos CreditAttribution: merlinofchaos commentedI complain to the powers that be about that regularly.
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.
Comment #19
higherform CreditAttribution: higherform commentedAlso 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.
Comment #20
jason.fisher CreditAttribution: jason.fisher commentedAgree with the request for the ability to resume editing a 'lost' session.
Comment #21
ExTexan CreditAttribution: ExTexan commentedSame 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.
Comment #22
perelman.yuval CreditAttribution: perelman.yuval commentedHi 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.
Comment #24
perelman.yuval CreditAttribution: perelman.yuval commentedfix the whitespace
Comment #25
perelman.yuval CreditAttribution: perelman.yuval commentedComment #26
perelman.yuval CreditAttribution: perelman.yuval commentedComment #27
raxxraxx CreditAttribution: raxxraxx as a volunteer commentedThis 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.
Comment #28
raxxraxx CreditAttribution: raxxraxx as a volunteer commentedComment #29
vrwired CreditAttribution: vrwired commented#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!
Comment #30
Honza Pobořil CreditAttribution: Honza Pobořil as a volunteer commentedResume 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
Comment #31
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedThe 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.
Comment #32
DamienMcKennaRerolled. The code could use a slight tidying up to match the Drupal coding standards but I'll leave that for someone else.