Any advantage in changing Security Policy to "Lock to edit" from User/Group lock

[steen.jensen]

We have used "User/Group Lock" for a while now, with about 30 users in 5 different groups.
Here I use Group Lock for each groups Root node, so only that groups users can edit.

But Im not sure how to secure the common part (Master & reference object) of the repository, mostly for error or mistakes by novice users

Is was wondering if "Lock to Edit" would give me any more advantage as everything is locked by default,  but then I dont have the Groups as granularity as I understand the different between those security policy's.

[qwerty]

I always prefer Require User Lock to Edit. It's simply that you first need to think and lock before doing a change. The normal lock just leads to situations that people take locks and go on vacation, leaving a dead locked system behind.

q.

[Eve]

But Im not sure how to secure the common part (Master & reference object) of the repository, mostly for error or mistakes by novice users

A user can be part of more than one group. So if it helps you can add groups for master and reference editors.

The normal lock just leads to situations that people take locks and go on vacation, leaving a dead locked system behind.

Not sure that "lock to edit" solves that.

[qwerty]

The normal lock just leads to situations that people take locks and go on vacation, leaving a dead locked system behind.

Not sure that "lock to edit" solves that.

It does not solve it, but from a psychological standpoint it makes the situation less probable.

q.

[Geert Bellekens]

I'm a fan of Require User Lock to Edit as well.

It doesn't prevent people from taking lock of parts of the model they shouldn't but I think that is more a problem in the heads of people than that it actually happen.

I've never seen someone who is correctly informed of his "part" of the model take a lock on another part and start editing stuff he/she shouldn't.
If you really want to pin it down and set security on packages you can link the packages to version control and use the security in the version control system to control who can edit the package.

As for having the "locked" problem, there is a feature in EA to unlock any lock by a user, so you can use that (it's not the most userfriendly dialog with 1000's of locks, but it gets the job done)
We also use a little EA-Matic script that pops up a dialog at the moment a user closes a model and still has locks. If the users agrees the lock are then cleared automatically. This prevents most of that type of issues.

Geert

[Mauricio Moya (Arquesoft)]

I prefer this option unchecked and lock all the model with different group locks. It is more complicated to set up because you need to define all the groups and restrictions first, but it is easier to use, because all users know that they can edit where they see the blue lock only. If lock is red, they only can view data.

[steen.jensen]

A followup question: Anyone using groups to separate users in skills,  as New, Novice, Skilled and Expert with different settings in security attribute??
Understand the manual labor to maintain those groups