User Security - hiding items?

[Paolo F Cantoni]

Looking through the list of permissions in the User Security sections of the help file, there doesn't appear to be a way in which one could (if one needed to) "hide" an item (whether, element, package or diagram) so it would not be visible to certain users in the browser (or searches) etc.

Have I missed something?

If you are creating a corporate-wide repository - there may be a need for this.

Paolo

[Eve]

No, you haven't missed something. Enterprise Architect isn't about "hiding" information. There is not any support for what you're after and no current plans to add it.

[Paolo F Cantoni]

No, you haven't missed something. Enterprise Architect isn't about "hiding" information. There is not any support for what you're after and no current plans to add it.

Thanks Simon,

I was just after confirmation.

While I agree that, in principle, the repository should be about exposing as much as possible to as many as possible; it does seem to me that there is a place for restricting - not just access - but visibility in some circumstances.

What do others think?

Just canvassing opinions - so I can better understand the nature of the problem and come up with strategies, if required.

Paolo

[OpenIT Solutions]

Hi,

In the real world this is necessary if you want to put all your architectural assets in one repository - which eases traceability, analytics etc.

Consider the example where your modeling a TOM. An element of which could be a new org design. Not something you would want all modelers looking at until plans are confirmed and communicated.

You could put this TOM design in a separate repository. But what if you want to trace/model the impact on current state ?

As ever with Sparx there are several "alternatives" - you could just use VC (without a DB backing it). Then on the VC system restrict access to your TOM packages.

Or look at creating several repositories backed with a DB, but using VC or the Reusable Asset Service (as your requirement dictates) to pull in the elements of the model you need / have access to...

Both these alternatives are in my mind problematic from an admin perspective (when you have a large model - with lots of uses - as is the case in the real world :-)).

[qwerty]

I just can say: thumbs up for Simon. Exactly what I pray  

q.

[Paolo F Cantoni]

I just can say: thumbs up for Simon. Exactly what I pray  

q.

I take it you're saying NO hiding?

And yet, elsewhere, you argue for customisable browser...  

(Off-duty Smart-arse  )
Paolo

[qwerty]

Point taken. But as I said elsewhere: If someone asks me to open the window to jump off the 10th floor I'd open it. So having it configurable is another way to open that window. Though I understand that making the appearance of the browser less crowded has it's pro's the lack of seeing everything is the back side of the medal. Having it configurable would give you a way to handle the open window your way.

q.

[Paolo F Cantoni]

Point taken. But as I said elsewhere: If someone asks me to open the window to jump off the 10th floor I'd open it. So having it configurable is another way to open that window. Though I understand that making the appearance of the browser less crowded has it's pro's the lack of seeing everything is the back side of the medal. Having it configurable would give you a way to handle the open window your way.

q.

I think a better way to look at it is not "Not seeing everything", but "seeing everything you ought to see".  (as mentioned by OpenIT - a real name would be useful  )

Logically, if I can restrain you from changing something (for enterprise reasons), I should be able to restrain you from seeing it in the first place.

One of the things that has frustrated me over the (now) decades is insufficient cognisance of the needs of enterprise level and wide users for a product whose moniker is "Enterprise" Architect.
The creation of enterprise-wide repositories is still difficult with EA, not impossible, just difficult.

Mind you, the others (competitors) have their own sets of problems in the same space.

Paolo

[qwerty]

I'm with you. But definitely there is the pricing problem. To create something Enterprise-like you will also need Enterprise-like prices. So I can live with the situation. And likely most consultants are fine with that too. Better pay them to adopt EA rather than paying Sparx for a tool that already fits. Hmmm. When I think of SAP the situation is that both SAP and consultants take Enterprise-charges.

q.