Book a Demo

Author Topic: Permissions for specific package  (Read 4432 times)

pzu

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Permissions for specific package
« on: July 09, 2012, 10:53:54 pm »
Hi,

Is there any way (Security Scripts) to give users permissions to selected packages ?

Like UserA has (edit or any other) permission for PackageA and UserB has (edit or any other)  permission for PackageB in the same project.

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Permissions for specific package
« Reply #1 on: July 09, 2012, 11:49:48 pm »
If you enable security you can simply lock by groups.

q.

pzu

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Permissions for specific package
« Reply #2 on: July 10, 2012, 12:03:59 am »
I have Security and Require User Lock to Edit enabled .

Could you tell how can I realize my requirement in more detail?

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Permissions for specific package
« Reply #3 on: July 10, 2012, 02:05:54 am »
Bad luck then. If you use RLTE then group locking is not possible. However, I never had a real use case where a group locking was needed. In the end you deal with a couple of modelers. If any of them decides with applying the edit lock to change something you can be sure there is a reason. (Maybe the reason is to kick someone in the ass to modify something where he shouldn't have done.) We also have auditing turned on in order to find out who has done what.

If you *really* need both you can implement a trigger which evaluates the security tables (see my Inside book). But that's going to be tricky.

q.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Permissions for specific package
« Reply #4 on: July 10, 2012, 04:04:24 pm »
Another way is to use an external version control system, and use the security features of this VC to control who gets to checkout what.

Downside is that checking in/out can take a while.

Geert

pzu

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Permissions for specific package
« Reply #5 on: July 10, 2012, 08:24:47 pm »
Thanks guys again for your expertise.

I'll look into Package Lock & Auditing features some more.


It looks like you both have huge experience in using EA in big teams.

Maybe you could share with me your observations on collaboration in EA. Any do's and don'ts would be very appreciated by me  :)

like fundamental question what's better DMBS or VCS ?
« Last Edit: July 10, 2012, 08:27:02 pm by pzu »

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Permissions for specific package
« Reply #6 on: July 10, 2012, 11:37:51 pm »
I burned my fingers with VC which is why I recommend to use RLTE, auditing and nightly snapshots. The story behind is somewhat lengthy. I had posted something related and will try to find the link to post it here.

q.
« Last Edit: July 10, 2012, 11:38:53 pm by qwerty »

pzu

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Permissions for specific package
« Reply #7 on: July 10, 2012, 11:50:56 pm »
I feel that collaboration on DB is somewhat better. As far as I know merging changes in VC is hard and error prone.

@querty
It would be great to read about your eperiences. I'm especially intrested why is RLTE better solution then simple security (optimistic locking).

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Permissions for specific package
« Reply #8 on: July 11, 2012, 01:24:55 am »
Read here: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1319704883/7#7
Of course it's not the complete truth, but maybe it gives a little insight. In the end the "correct" solution needs to be found be try and error. There is no silver bullet.

q.