How to hide packages from users / user groups?

[jakson]

Is there any way to hide some packages from some users or user groups?
I know that I can create another database, but this is nasty workaround.
PS I have EA v12.1.1230.

[Uffe]

No. Within a project, everything is visible to everybody.

/Uffe

[qwerty]

I never found anyone who could explain why someone wants to hide model parts from others. If there's really classified information, place it in a restricted repository. If there were any way to hide things in EA it would be easy-peasy to work around that since EA needs open access to all tables. And SQL is something, anyone can code.

q.

[Glassboy]

I never found anyone who could explain why someone wants to hide model parts from others. If there's really classified information, place it in a restricted repository. If there were any way to hide things in EA it would be easy-peasy to work around that since EA needs open access to all tables. And SQL is something, anyone can code.

If you're working on process reengineering then someone could infer staff redundancies from the models.  I've always created a separate secured repository for this type of work.

[Paolo F Cantoni]

I never found anyone who could explain why someone wants to hide model parts from others. If there's really classified information, place it in a restricted repository. If there were any way to hide things in EA it would be easy-peasy to work around that since EA needs open access to all tables. And SQL is something, anyone can code.

If you're working on process re-engineering then someone could infer staff redundancies from the models.  I've always created a separate, secured repository for this type of work.

Was the secure repository self-contained or did it share elements with the public one?

If shared, how did you synchronise them?

Paolo

[jakson]

I never found anyone who could explain why someone wants to hide model parts from others.

We have main (and only) EA database. Access to the database have permanent employees.
Now we have a few temporary workers and they have to have access to EA database, but only to one specified package (and to "common" package with data types and other common stuff).
The only solution is another database?

[qwerty]

Yes. Make the according packages (version) controlled and hand them out to the external guys. You would then merge their changes when they are done. Here I have in mind that the external parts are a (small) subset of the main repository which can be decoupled. If you have a structure where you have just little key parts that need to be hidden, this will not work well. Though, if those classified parts are minor, I wonder what kind of model information is held so it needs classification.

q.

[Glassboy]

If you're working on process re-engineering then someone could infer staff redundancies from the models.  I've always created a separate, secured repository for this type of work.

Was the secure repository self-contained or did it share elements with the public one?
If shared, how did you synchronise them?

It contained several copies of the production repository.  No synchronisation.

[Paolo F Cantoni]

If you're working on process re-engineering then someone could infer staff redundancies from the models.  I've always created a separate, secured repository for this type of work.

Was the secure repository self-contained or did it share elements with the public one?
If shared, how did you synchronise them?

It contained several copies of the production repository.  No synchronisation.

So just to be clear, the secure repository contained static snapshots of the public one.  Even if the  public repository evolved, the secure repository didn't see these evolutions.

Paolo

[Glassboy]

So just to be clear, the secure repository contained static snapshots of the public one.  Even if the  public repository evolved, the secure repository didn't see these evolutions.

Yeah, what if modelling of business processes.  Business processes don't randomly change by themselves in a managed environment.  Our modelling could have lead to changes.

[Paolo F Cantoni]

So just to be clear, the secure repository contained static snapshots of the public one.  Even if the  public repository evolved, the secure repository didn't see these evolutions.

Yeah, what if modelling of business processes.  Business processes don't randomly change by themselves in a managed environment.  Our modelling could have lead to changes.

I think I follow.  You wanted to test What if Modelling of business processes.  Each scenario (perhaps) within its own sandbox.  Because of the nature of business process modelling, the changes shouldn't be published until ratified etc.  Hence the secure repositories.

Did I get it right?

Paolo

[Glassboy]

Yes.

[qwerty]

My argumentation in this case is to put the relevant parts under a clear development root. So they can be reviewed by all stakeholder. I have never seen people cheering when presented a jack-in-the-box. But I never have worked in an area where classification is an issue - and likely will never start there.

q.

[Guillaume]

Some of my clients have requested a feature that hides packages in the Project Browser from users due to their EA model structure.
In one situation, the EA project had model roots for each "product": there was a clear need to hide model roots from user groups (there was reasons and constraints for running such structure)/
For another situation, there was a need to hide packages so stakeholders and reviewers could use EA to review the model branch that was relevant to them.

So I think there are purposes for such feature, however I didn't get a positive answer from Sparx on my request.

For the latter case (review), I think a tool with a web interface could easily let one manages what needs to be visible for certain users.

[Uffe]

But I never have worked in an area where classification is an issue

I have, and I can tell you that with EA's security model, any client-side hiding of parts of a repository would never pass a security review. This is because the hidden information is easily obtained from the source (the database) with a minimum of effort using publicly available tools.

Information security is simply not a part of EA's design. Any such requirement within an organization will need to be realized using multiple repositories with some form of selective synchronization, or HTML exports if read-only access to the models is sufficient.

Possibly something could be implemented in the cloud server, but I think it's just too much work for too small a segment of the user base.

If on the other hand the issue is not information security but convenience, and model views don't cover your needs, you could always write an Add-In with its own tree view.

/Uffe