"Effective Permissions"

[Paolo F Cantoni]

We have three groups:
MAs - Modelling Administrators
EAs - Enterprise Architects
SAs - Solution Architects

My colleague is a member of all three.
We decided to remove the ability of SAs and EAs to lock elements but leave that ability to MAs.  (We lock all elements by Groups and we didn't want individuals to "muck up" the existing locking by accidentally moving the lock to a different group etc.)

Once we made the change to remove the permissions, he couldn't lock any elements even though he had permission as an MA.  Many products have the concept of "effective permission".

Before I report this as a bug, is it?  Or is EA behaving as it should?

TIA,
Paolo

[Eve]

I expect group permissions to be cumulative.

Just double check that he is in the appropriate group. It looks like it should be working to me.

[Paolo F Cantoni]

I expect group permissions to be cumulative.

Just double check that he is in the appropriate group. It looks like it should be working to me.

Hi Simon,

By that you DO mean that if he had permission to lock element in any group he belonged to, he should be able to lock the element.

Once you confirm that, I'll check my side - as he's not around at the moment.

Paolo

[qwerty]

Actually I guess he meant that since this is what I remember to be the behavior.

q.

[Eve]

The 'Lock Elements' permission (whether given specifically to a user or coming from any group that they are part of) allows the user to apply a lock to any unlocked element. (And I assume remove/change a personal lock or group lock for a group he is part of)

However, I think I can give a likely explanation for what is going on.

EA only allows you to apply a group lock to a group that you are part of. If this user is not a member of EAs or SAs, he would only be able to apply a group lock for MAs. (ie. He can't apply the locks he needs to rather than he can't apply any locks)

[Paolo F Cantoni]

The 'Lock Elements' permission (whether given specifically to a user or coming from any group that they are part of) allows the user to apply a lock to any unlocked element. (And I assume remove/change a personal lock or group lock for a group he is part of)

However, I think I can give a likely explanation for what is going on.

EA only allows you to apply a group lock to a group that you are part of. If this user is not a member of EAs or SAs, he would only be able to apply a group lock for MAs. (ie. He can't apply the locks he needs to rather than he can't apply any locks)

Ahh... That's seems to agree (with, at least my recollection, of) what happened.  As I said, when he's next around I'll check.
[edit]Sorry, he IS a member of those groups, AND of MAs; but the Group lock was set to SAs when they were allowed to set locks.  We THEN took that ability away.  That's a slightly different use case[/edit]
However, is it possible to be more definitive on Sparx's part?  Does the documentation need to be enhanced to make this clearer?  We're setting up a NEW system for new users of Sparx and we don't want to alienate them with questionable UX.

Paolo

[Eve]

Maybe you should wait until this person comes back and send in a support request detailing exactly what the scenario is, what messages are shown and when.

I can't see any reason why removing lock permissions from one group would change any behavior for a member of a group with lock permissions.

[Paolo F Cantoni]

Maybe you should wait until this person comes back and send in a support request detailing exactly what the scenario is, what messages are shown and when.

I can't see any reason why removing lock permissions from one group would change any behavior for a member of a group with lock permissions.

He's back now... Making sure that he logged out of EA as we made each change, the security seems to be working the way we expected it to.

Thanks for your help Simon.