EA Security

[JeffM]

Does anyone know if there is a way to restrict access to a group in the EA Security while also using the "Require User Lock to Edit" feature?

Thanks.
Jeff M.

[nara_c]

Hi Jeff,

It appears Group level access control can only be set when the security model option "Require User Lock to Edit" is turned off.  Whereas User explicit locking is only possible when it is turned on.  Bit of a conundrum    But I believe this is by design.

EA documentation explicitely states:
"Security in EA is not designed to prevent unauthorized access: rather it is intended to provide a means of improving the collaborative design and development  by preventing concurrent editing and limiting the possibility of inadvertent model changes by users not designated as model authors."

If you read the help section on "Security Policy" they have guidelines on which option is best for what types of teams.

You will need to judisiously consider why you want to enforce both Group level control and explicit user locks and decide on what is best for your environment.  

One caution is that when a Group level access lock is placed EA seems to behave a bit strange if the proper person does not enforce the group lock.

For instance, when a user who is part of one group such as 'Administrators' locks a package & its children for another group say 'Developers' the system displays some warnings on the lines of "you are not part of the grup and will get locked out" and if you choose to continue the locks only seem to apply to elements and diagrams but not packages.  

Further the Admin is able to edit the elements though they are not part of the group due to the way the locks applied.  If you check the View locks list display you will notice that the elements of the package are locked for the Developers Group and the Admin user.

The same process works fine when done by a person who is a member of the group that the lock is applied for (i.e.) all elements of the package including sub-packages are locked for the target group.  Hence the package structure and configuration management should be well planned.

Alternative : Version Control
Another option you may want to consider is to enable Version control and then use that to make changes and track access.  This seems to have a similar effect in that once a package is under version control, it or the elements or sub-packages within it can only be edited by checking them out first.  Also provides a nice Audit trial which is not natively available in EA.

Note that Version control disables Group/User locking for the packages that are under version control.  I assume that under this scenario, Security is intended to only allow valid users to connect to the model.  It is expected that Version control will replace Group/User Security for controlled packages and only packages not under version control can be controlled via Group or User locks.

Hope the issues I highlighted will help you in deciding the best security model for you project.  Would like to know how you got along.

[JeffM]

Thanks so much for such a complete answer!  I have been away from the forum for a bit and had actually already decided to use the group locking - just to keep different projects from accidentally trashing something - and we also use Starteam for version control.

At the time I asked the question I hadn't fully taken in the whole integrated process but now we are using it in a multi-project/multi-user single Oracle repository version controlled environment.  I just really haven't had time to post my findings!

Again thanks for the information.  Hopefully this thread will help someone else in the future as well.  

Jeff M.