Author Topic: 'Require user lock to edit' and group locking (Read 13821 times)

andykennelly · « **on:** June 19, 2013, 05:57:07 pm »

I've security enabled my project (with 'Require user lock to edit' turned off) and created users within user groups. I've then locked certain folders against certain user groups. This means that the contents of folders can be updated only by those users in the relevant user group.

So far, so good.

I'm now exploring how to have all elements un-editable until a user locks them against themselves to perform edits. As far as I can see, the only way to do this is to turn on 'Require user lock to edit'. However, this means that I can't implement my group locking approach ..... indeed, all group level locks are removed once 'Require user lock to edit' is turned on.

Is there any way that I can allow updates against a folder only for users in a certain group AND make elements in that folder un-editable until the user locks them against themselves (i.e. until the user implements user level locking over and above the group level locking?

?

Helmut Ortmann · « **Reply #1 on:** June 19, 2013, 07:42:13 pm »

Hi,

possible solutions I have in mind:
- Write an Addin
- Use Version Control and manage rights there

Kind regards,

Helmut

qwerty · « **Reply #2 on:** June 19, 2013, 09:10:58 pm »

Is it just me seeing this as strange behavior? Why are people so keen to LOCK models against changes? A model is used to communicate. Locking out people from changing the model is like censorship. No good for communication. The RLtE is a minimal approach which hinders people from accidentally deleting elements. More is just superfluous.

q.

andykennelly · « **Reply #3 on:** June 19, 2013, 10:41:53 pm »

Hmmm ... yeah, I see your point, Q.

We have a big model covering disparate aspects of our organisation, and a large user base. The group-locking-at-folder level approach is an option to apply some domain governance, such that a domain (folder) owner could have some confidence that his folder was being updated appropriately (since he controls who is in his group).

However, this approach is onerous and heavy weight and we are also considering simply applying 'Require user lock to edit' and trusting people to communicate appropriately to ensure the right stuff gets done in the right folder (as you suggest).

The Sparx security functionality is quite rich, though, and various patterns are discussed in the help files ..... ... do people tend to use it in some way other than how I've outlined? Or does your point also imply that the default position is that nobody really needs to use any of that function at all?

qwerty · « **Reply #4 on:** June 19, 2013, 11:08:16 pm »

YMMV - Quite a number of people asked for finer granularity of the locking scheme. From an admin's view who is paid for administrating these it's logical. From a user perspective (as pointed out) it isn't.

I have tried various approaches to enable collaboration but the best one was simply to use RLtE. There are definitely use cases with distributed groups where a central RDBMS does not work so well. However, any other solution will open the door to different hells. Probably there are tools out there which offer better collaboration support (I don't know, just guessing) but you have to pay a factor in licenses compared to EA.

q.

andykennelly · « **Reply #5 on:** June 19, 2013, 11:37:10 pm »

Nice one. Thanks, Q.

Geert Bellekens · « **Reply #6 on:** June 20, 2013, 04:45:38 pm »

We also use Require User Lock to Edit, and we have some packages in VC so those packages can only be edited by a certain subgroup of users.

Geert

Graham_Moir · « **Reply #7 on:** June 20, 2013, 07:24:33 pm »

You could also use baselines and turn on auditing, and communicate out that these are in place - then destructive rogue edits are perhaps less likely as you'll be able to trace them.

Viking · « **Reply #8 on:** November 30, 2016, 11:27:55 pm »

Quote from: andykennelly on June 19, 2013, 05:57:07 pm

I've then locked certain folders against certain user groups. This means that the contents of folders can be updated only by those users in the relevant user group.

Could somebody tell me what to do in Sparx EA to get the same result? I hope that andykennelly is not talking about RLtE.

If it is possible to set update-restrictions, is it also possible to set read-restrictions with Sparx EA? I am not talking about Database permissions.

Geert Bellekens · « **Reply #9 on:** November 30, 2016, 11:35:07 pm »

You cannot set read restrictions other then having different repositories (databases or .eap files)

Write restrictions could be handled using group locks, but then you loose the concept of RULTE where everything is read-only until you specifically (and consciously) take a lock on something.
If your group has a lock on something everyone in the group can edit it, without having to do anything special.

That is why I prefer to use version control if write restrictions are required.

Geert

qwerty · « **Reply #10 on:** November 30, 2016, 11:45:10 pm »

Exactly, Geert. And the habit to first-lock-then-change saves a lot of headaches that comes from "accidental" changes.

q.

Viking · « **Reply #11 on:** December 02, 2016, 02:59:23 am »

Dear Geert, Thank you very much. The statement "If your group has a lock on something everyone in the group can edit it, without having to do anything special." was very helpful. I did not know this before.

Please allow 2 further questions.

I see following options:
(1) “Project” > “Security” > “Require User Lock to Edit” (RULtE)
(2) "Project" > "Enable Security" > in check box “Automatically apply Exclusive Edit Locks to diagrams”
(3) Right click on Element > "Full Lock"
(4) Right click on Element > "User Lock"
(5) Right click on Element > "Group Lock"

Is it correct, that (1) and (4) are similar: (1) sets a lock automatically, (4) upon request?
Is it correct, (2) and (3) are similar: (2) sets an exclusive lock automatically, (3) upon request?

V

qwerty · « **Reply #12 on:** December 02, 2016, 08:05:08 am »

a) No. Default for security is: everything is unlocked. You apply a lock to lock it for a user or group. RULtE works vice versa. Everything will be locked. You unlock elements/packages for yourself or a group.
b) No. 3) 4) and 5) are just the scope for which the lock is applied. In RULtE it will work opposite to normal security (see a).

q.

Viking · « **Reply #13 on:** December 02, 2016, 07:53:47 pm »

Quote from: qwerty on December 02, 2016, 08:05:08 am

a) No. Default for security is: everything is unlocked. You apply a lock to lock it for a user or group. RULtE works vice versa. Everything will be locked. You unlock elements/packages for yourself or a group.
b) No. 3) 4) and 5) are just the scope for which the lock is applied. In RULtE it will work opposite to normal security (see a).
q.

Thank you very much, q. This makes things much clearer to me.

Unfortunately I do not understand the role of (2) ("Automatically apply Exclusive Edit Locks to diagrams") in this context. For me, it as a completely diffenrent meaning now. It does not have something to do with the locks, you are talking about. It just sets an exclusive write lock in the database (instead of optimistic), as soon as I change a diagram.

Is that correct? If not, could you put this in your frame as well, please?

Many thanks in advance

V

qwerty · « **Reply #14 on:** December 02, 2016, 08:50:19 pm »

Digging in he mud here as I have currently no suitable test environment set up and I never used (2). See the help http://www.sparxsystems.com/enterprise_architect_user_guide/12.1/the_model_repository/usersecurity2.html at 4. I think it's explained well.

q.

Sparx Systems Forum

News: