Author Topic: Locking a root node without child packages in User/Group policy  (Read 299 times)

wlodekw

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Locking a root node without child packages in User/Group policy
« on: September 13, 2017, 02:09:09 am »
Hi,
We have a MySQL-based model repository in my company, I'd like to lock a root node (named for example 'Model') so no one can add 1st level child packages to it.
This does not seem to work however, with the User/Group policy. If I try to lock the root node so that no one (not a user nor a member of a group) can edit it - nothing happens.
We've chosen this policy to get some flexibility in allowing access to certain parts of the model.
Is it possible to lock the root node at all in this mode or should I switch to user-lock policy?
BR,
Włodek

qwerty

  • EA Guru
  • *****
  • Posts: 8914
  • Karma: +134/-122
  • I'm no guru at all
    • View Profile
Re: Locking a root node without child packages in User/Group policy
« Reply #1 on: September 13, 2017, 05:54:18 am »
Both policies work exactly the opposite way. In RULtE (which is the lock I prefer= you need to apply a lock and can edit afterwards. So only one person can work on an element. The other policy lets everyone work on the element and only when it's locked, just that person/group is allowed to edit.

In your case you need to write an add-in that locks the top package and then iterates through the single sub-packages to unlock them. Try this manually first. I'm not sure if it really works I expect it to do (I have not enable security at the moment).

q.

wlodekw

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Locking a root node without child packages in User/Group policy
« Reply #2 on: September 13, 2017, 07:59:58 pm »
In User/Group policy I cannot lock the root node, regardless of the options I use in the locking window.

I was hoping to build a model tree that has certain areas of the model locked by certain groups(roles), not exact user accounts as I do not know them yet.

For example:
Requirements model - locked by group named Systems analyst
Architecture - locked by group Architect
Tests - Tests engineer

I need an administrative account (or group/role) to be able to do this. Sadly, Enterprise Architect offers almost no flexibility to pre-configure the permissions for the model. I have to log in as a certain user to lock the package in his name.

This is partly solved by adding the admin account to every such group and applying group locks as in the example above. This gives some flexibility and allows to delegate control of a given package to a group. Within that group there can be conflicts and data loss of course, but these are confined, and users are urged to lock their work in their account's name. But then they can release that lock and allow other members of the group to work with them.

So when users connect to the model, there is a structure in place and permissions are set for them to work in certain areas while others are, from the start, read only.

Right now the only thing that ruins this approach is the root node which I cannot lock.
Is there a way to do this at all, even if it takes a SQL command on a raw DB ?

qwerty

  • EA Guru
  • *****
  • Posts: 8914
  • Karma: +134/-122
  • I'm no guru at all
    • View Profile
Re: Locking a root node without child packages in User/Group policy
« Reply #3 on: September 13, 2017, 09:00:50 pm »
I had no issue un-/locking the root package in either policy.

q.

wlodekw

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Locking a root node without child packages in User/Group policy
« Reply #4 on: September 13, 2017, 09:25:40 pm »
With User/Group policy I am unable to lock a sole package without any child elements/packages. I was mistaken in my 1st sentence, when including children you can actually do that. But in order to achieve what I want I'll need to go Top-Down the model tree and rewrite all that was done before.
Are you able to lock a package without any children in User/Group policy? In RULtE policy you can do that.

qwerty

  • EA Guru
  • *****
  • Posts: 8914
  • Karma: +134/-122
  • I'm no guru at all
    • View Profile
Re: Locking a root node without child packages in User/Group policy
« Reply #5 on: September 13, 2017, 11:33:23 pm »
The Apply Lock (in non-RULtE mode) has a Process Child Packages. But that behaves sparxish. As said: I prefer RULtE.

q.

wlodekw

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Locking a root node without child packages in User/Group policy
« Reply #6 on: September 14, 2017, 01:48:12 am »
Well, in User/Group policy and EA 13.5 this is accessed by Package Control | Lock Package.
When a top (not the root at the moment) package has child elements this happens when I try to lock:
  • select Full lock only - nothing happens
  • select Full lock and Process Child Packages only - nothing happens
  • select Full lock and Process Child Packages+Lock Diagram - the package and all child diagrams are locked
  • select Full lock and Process Child Packages+Lock Diagram+Lock Elements - the package and all child elements are locked
The same is for User lock and Group lock, and the same if the Package is empty. I tried other combinations too.

The missing feature for me in the User/Group policy is the ability to lock a sole package without any children (as is possible in the policy you call RULtE). This is in order to prevent someone from adding child packages and/or other artifacts directly as children.

Anyway, big thanks for clarifications. I think I managed to achieve what I wanted, it was just quite unhandy to setup. I suppose the word 'sparxish' explains a lot ;).

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5862
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Locking a root node without child packages in User/Group policy
« Reply #7 on: September 14, 2017, 10:05:33 am »
We also found issues with locking packages and items via the UI.  After our overnight processing, we need to re-lock our repository according to a certain regime.  We do this by running a series of queries directly on the database.  This has worked for at least two years.

Look at the t_sec* tables for information

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!