Resources in use don't show as locked

Hey, did anyone else notice that resources in use by other users don't show as locked anymore? I've only noticed this since using 2.2.4-pl, but it can get a little confusing when a user can't save because I'm using the same resource.

Is there some setting I don't know about to turn this on?

Default behavior for this only works if you are not an admin or SUDO user. If it is applying to non-admins/non-sudos, then you are correct and this could be a real issue. In other words, you will never see such a lock yourself. Also, are you sure they aren't clicking "Remove all Locks" in the menu?

There is such a setting: Lock Time-to-live (lock_ttl) can affect a such lock, by shortening the lifetime of the lock. When locking, a lot depends on timing. If they open the resource before you do, they will never see the lock, and because you are admin, neither will you. This results in the behavior you describe. Additionally, the lock may get extended by saving, etc, this can result in further confusing behavior.

There are two permissions that can be particularly troublesome, so you may have to check your ACLs. "remove_locks" simply allows a user to click it in the menu. "steal_locks" silently allows a user to steal the lock from other users. If this is set, they will never get notified of a lock. However, it still obeys priority, so a user can never "steal" the lock from an admin or sudo. This also results in the behavior you describe. They access a resource, but you have the lock. They have "steal_locks" so they are never notified, but the lock was never actually stolen.

Note: This is why on many systems, admins will move the resource to a different resource group while doing the editing and move it back when done. Since this is a common issue on many database systems, it might have been taken for granted.

Another Note: An sudo can steal a lock from an sudo, but neither will be notified, allowing both to make conflicting changes to the same resource. In these cases, the lock only locks out everybody else that isn't sudo.

That's all very interesting, I'm impressed with your quick grasps of MODX every time you post Fuzzy.

What's even more interesting, is I've only ever seen the locks with other Admin/Sudo users. But that was in 2.2.2, so I figured something had changed in 2.2.4.

Actually, the creators of any database systems are fighting a constant war. The argument always applies to admins and locks. For extended periods of time, no admin wants to have to be notified of a lock. Then after all of the problems that arise with that, all admins want to be notified everytime. Then after that, admins should have to click a button to steal a lock. Then after that, admins should steal the lock silently. Its been going on since DBMS began. [ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]

@frogabog - did you dig any deeper with this? I'm working on a system (2.2.4) with multiple content editors.

They've recently complained of making changes, saving and then 10 minutes later seeing the changes revert back to what they were previously.

We realised this was because someone else had the same resource open and saved it *after* the other person had made changes, writing it back to the original state. This has caused huge frustration.

In Evo people were always getting locked out of resources, but as an admin user I've never noticed the lack of 'lockouts' in Revo until now. I've gone through the docs and System Settings, stopped short of going over the permissions code. My editors all have greatly reduced access permissions yet they are always able to edit a 'currently open' resource.

Am I missing something in plain sight here? [ed. note: okyanet last edited this post 13 years, 11 months ago.]

Check the properties of the user roles. I believe I saw a "can steal locks" or something like that in there last week but I'm not sure which role I saw it in.

I experienced locks with another admin user last week while we were on the phone editing an article. I had no save option while she was editing, but in Articles since there's nothing in the tree, no lock shows up there (or elsewhere prior to opening the resource) to warn you. We didn't edit any regular resources that day, maybe the lock would have shown then?

Edit: you may want to install VersionX from package management. At least that way, if you need to revert to an earlier version, it's available.

That's definitely in there, there are a number of permissions related to overriding locks. But those users are all working under a custom Access Policy and everything to do with locks in unchecked..

When you saw the locks last week, was that with 2.2.4 or have you upgraded? I'm not able to do that just yet.

Anyone else seen this problem? Or is it just me!

The locks were in 2.2.4, but I didn't see them in the tree. Save wasn't available in the resource, or I wouldn't have known it was locked. This was admin to admin actually and she's the default (thanks to her old server and simple scripts).

I'm going to adjust the users and put her on a more restricted user soon so I'll keep looking for it. I did upgrade to 2.2.5 about three days ago.

About the steal locks permission, I think it was before the upgrade. I think...

I've tested admin to admin, editor to editor, and editor to admin. No locks.

Anyway, I'm going to do a completely fresh install and test it out with some standard user policies. If that works then I know I've done something wrong.

I'm seeing locks in 2.2.5, admin to editor right now (have an editor open in one browser, and I'm logged in in another).

This is how I've got it set up. I'm sure something is wrong, but it works as is.

Users:
Editor: Role: AdminEditor.
Default Admin: Role: Super User

Context Access:
both mgr and web minimum role is AdminEditor, access policy is EditorAdmin.


Resource Groups:
allDocs - Role: Super User, Access Policy: Resource, context: mgr
AdminEditor - Role: Editor, Access Policy: EditorResource, Context: mgr
View Only - Role: Editor, Access Policy: ResourceViewOnly, Context: mgr

Roles:
AdminEditor: Authority 10
feViewer: Autnority 20

Access Policies:
EditorAdmin: Duplicate of Administrator Policy with all 172 permissions
EditorResource: Duplicate of Resource Policy with 14 permissions
ResourceViewOnly: load, list, view, add_children (ACK! there it is! - the steal_lock permission - in the default Resource policy and ResourceTemplate)
feVeiw: load, list, & view


If you missed it, the steal_locks is in the ResourceTemplate and Resource Policy. Do you see it?