Synchronize stereotype without user lock

[Oliver F.]

Well, it seems as if the stereotype synchronization operates without having the need to apply a user lock on elements.

After acknowledging the dialog it runs through and does not care who has locked an element. It simply sets the tagged values and constraints.

Wondering if this is by intention.

Oliver

[Geert Bellekens]

Oliver,

I found that anything except an Element.Update() doesn't care about whether or not the element is locked.
On the GUI some of those functions (like adding tagged values) are disabled when an element is locked, but apparently that security check is only done on the GUI and not on the internal objects themselves.

Yes I agree, major design flaw

Geert

[Oliver F.]

Yes I agree, major design flaw

Guess what I did?  8-)
Gave Sparx something to do and filed a bug report:

Code: [Select]

The user lock is not considered for various activities which are not directly applied via user interface.
Eg. synchronizing tagged values and constraints is applied immediately without considering user locks.
This looks like a major design issue and is highly dangerous im multi user scenarios.

Apply a stereotype from eg. a UML profile to several elements.
Then change the stereotype by adding constraints and tagged values, recreate the UML profile.
After ativating the new profile version apply user lock to some elements and to others not. When synchronzing the stereotype all elements are adapted to the new tagged values regardless their locking state.
BTW I once created an external program which writes information and taged values into elements and here I ran into a user locking error.
From my experience it is not consistent.

Oliver

[Dave.B]

Sparx have got to ensure that the model database reflects the associated checked in XMIs otherwise chaos will take over and everyone will get cross.

Sometime ago a told them that the model based spell check would allow corrections to be made to checked in packages. I think they fixed this, but as I haven't tried it in a while it would be worth checking!

Dave B.

[Geert Bellekens]

I actually found that there is a difference when a package is checked out using version control, or whether a package is locking using the build-in security feature.
The build-in locking allows you to add any relation you want to read-only classes, where the version control locking only allows to add a relation when the read-only class is the target.
Through the API it allows you to add issues to elements, add/update/delete attributes and operations, and more. (I haven't tried everything).
It could be that in general EA is more strict when version control is used to lock elements.

Geert