Strange lock behaviour

[Uffe]

Hi!


I am in a DBMS repository, with the "Require Lock to Edit" policy.
I am observing the following locking anomalies in 9.0.905:

1) If I have a diagram open when locking / unlocking its parent package, the "Delete Connector" menu option in the connector context menu is wrong. It remains available when I lock the package, and remains unavailable when I unlock it.
   The latter is an inconvenience, but the former is potentially dangerous.

2) If I apply a lock on a diagram from within the diagram itself (not the project browser), I can then add new elements even though the parent package is not locked (ie, I cannot right-click the package and Add an element).
   If I do this, I can then not delete the element again (requires package lock).

3) The in-diagram Apply / Release User Lock menu options replace one another. They seem not to check the current lock status, but instead to remember which one of them was called last.
   In other words, you can lock the diagram using the in-diagram menu, then unlock it in the browser, and then unlock it again in the in-diagram menu.

These all seem like bugs to me, but I can find no specific reference to them in the version history. Can anyone say whether they have been adressed in 9.1, or reported to Sparx?

Cheers,


/Uffe

[qwerty]

I have similar observations.

1) Obviously all connectors can be changed regardless of the lock. I found this useful (sic!) and so did not report a bug.

2-3) Locking is stored per element. The context menu just looks into the selected element to set the radio button to the opposite. So that seems logical.

4) I have reported this bug:
-open a diagram
-apply recursive lock to its package
->diagram still locked. You need close/re-open

5) and this one:
- change a diagram
- release the lock
-> diagram changes are not saved and will be lost upon closing

q.

P.S.

6) You can rename the model root without any lock!

[Geert Bellekens]

I've noticed another one:

- You can move diagrams out of an unlocked (~readonly) package, but not into an unlocked package.

I'll submit a bug report for this.

Geert

[qwerty]

Despite these bugs this feature seems to be excellent when setting up shared models. Without these bugs it would just be marvellous.

q.

[Uffe]

2-3) Locking is stored per element. The context menu just looks into the selected element to set the radio button to the opposite. So that seems logical.

Well, not quite. The context menu appears to be controlled not by the actual lock but by a client-internal cached lock state, which is not updated correctly when the same client manipulates the lock in a different way.

6) You can rename the model root without any lock!

Also worth a bug report, I think, but I haven't sent one. I did send one off regarding my OP; I have a 100+ user deployment here, and locking simply has to work.

[qwerty]

I had reported 6) as well. Hope they fix all those bugs soon since locking is our last resort.

q.