Security groups and packages

[mmontminy]

Following post Security Question, I have the following question about Security groups and packages.

Groups are assigned a list of permissions. My understanding is that the permissions assigned to a group apply to the entire project and cannot be set at the root node (if I have more than one) or package level.

My use case is the following, in my model, I would have different architecture
•   Business Architecture
•   Application Architecture
•   Data Architecture
•   Technology Architecture

I would like my business users (via business user groups) to update assets of the business architecture but not of the other architecture domain (application, data, …). Same thing for user responsible for the other Architecture domain.

My intuition drove me to believe that I could assign groups to packages but it doesn’t look like it.

Is there any other way (with the exception of having multiple repositories) to achieve the same result?

[Geert Bellekens]

Martin,

You can use group locks or an external version control system to do that.

But are you sure you really need that?
Most of my clients setup security with "Require user lock to edit" and they explain the users which parts of the model they are allowed to edit, and which parts they are not allowed.

I have never seen a functional analyst change stuff in the business processes, or a business analyst go and edit parts of the architecture. People generally don't do that, especially not if they explicitly have to lock a part of the model in order to edit it.

Using an external version control system such as SVN or TFS you can assign edit rights to the version control repository. You can then setup different repositories for different groups of users.

Geert

[mmontminy]

I was actually reading on version control and was about to reply that it might be the solution.

I'm with you when you say if I really need that. People have way too much to do to go mess around. It's probably more to prevent accident. Trying to establish a relationship between different domains.

I'm working in a bank and trying to introduce E.A. as the central repository for architecture assets (instead of Visio, Excel and Word document scatters across SharePoint site). I just want to be prepared to in case it is required.

Thanks for confirming what I was trying to get me head around,

Martin

[qwerty]

EA's security is indeed nothing else but an "accidental deletion prevention", but as such it works pretty well. I remember the paranoid policies from banks. But finally if you can convince them that only approved personal has access to the model (which anyway is pnly accessible in the bank's environment) it should be possible to convince them of using EA. I always recommend to use EA with Require User Lock to Edit (and without any version control!).

q.

[Glassboy]

I would like my business users (via business user groups) to update assets of the business architecture but not of the other architecture domain (application, data, …). Same thing for user responsible for the other Architecture domain.

It's a model, not a file system.  There are connections between your levels.  Denying access to another level would remove the ability for a user to safely edit a connected element.

[Sunshine]

We have similiar need so how we set up our groups is via a kind of matrix
For example we have different levels or privilege depending upon skill level with EA. For example

• Beginner
• Intermediate
• Advanced
• Administrator

Where Beginner can do the basics and Administrator can do everything with the others incrementally having more privileges as their skill level improves. This helps prevent beginners having too much privileges beyond their skill level and messing things up. For example doing a CSV import.

The other security groups we have don't provide any privileges but are allow write privileges to certain areas of the model.
For example

• Business Analyst
• Architect
• Database Designer
• Tester
• etc...

And we use these groups to lock packages with group locks to only allow people assigned to those roles to edit those areas in the model.
By allocating the users to a role group and a privilege group they are given the appropriate access to the things they are allowed to do and the area's of their domain.
For example a junior business analyst would be assigned to "Beginner" and "Business Analyst"
Seems to work okay for the team of 15 or so.

[mmontminy]

I would like my business users (via business user groups) to update assets of the business architecture but not of the other architecture domain (application, data, …). Same thing for user responsible for the other Architecture domain.

It's a model, not a file system.  There are connections between your levels.  Denying access to another level would remove the ability for a user to safely edit a connected element.

I understand that. I still need to understand how to setup security so that members of group working on one domain can link to assets (Elements, Diagrams) of another domain.

Right now, security is not enable on our project. Group locking seems to be the way to go first. We are currently setting up our installation to be able to experiment.

Thanks all for your feedback!

[Sunshine]

I understand that. I still need to understand how to setup security so that members of group working on one domain can link to assets (Elements, Diagrams) of another domain.

Right now, security is not enable on our project. Group locking seems to be the way to go first. We are currently setting up our installation to be able to experiment.

Thanks all for your feedback!

My previous post covers that.