How to "Apply / Release User Lock" ?

[HelmutK]

Hello All,
we use the security "Apply/Release User Lock..." functionality in the Corporate Edition. I can't find a way to lock and edit element via the automation interface...

Code: [Select]

earep = new EA.RepositoryClass();
earep.OpenFile2(connectstring, user, password);
bool islocked = earep.GetPackageByID(3309).Element.Locked;
checking the lock i get TRUE, meaning its already locked by somebody

1. - how to identify the user ?
2. - how to remove lock as "Project | Security | Manage Locks..." in EA ?
3. - how to lock an element as "Apply/Release User Lock..." in EA ?

Thanks,
HelmutK

[Geert Bellekens]

Did anyone find the answer on this one?
I'm having the same problem trying to apply a user lock to a package from my addin.

[Geert Bellekens]

I've sent a support request to sparx about this issue. I'll post the answer as soon as I get one.

[HelmutK]

Hello Geert Bellekens,

the API don't support these desired features.

I solved the problem using folowing update and insert statements on our oracle database repository:

Code: [Select]

UPDATE t_seclocks s SET s.USERID = '<USERGUID>', s.TIMESTAMP =  to_date('<DATETIME>','DD.MM.YYYY HH24:MI:SS') WHERE s.ENTITYID = '<EA_GUID>';

INSERT INTO t_seclocks l (l.USERID, l.ENTITYID, l.ENTITYTYPE, l.TIMESTAMP) VALUES ('<USERGUID>', '<EA_GUID>', 'Element', to_date('<DATETIME>', 'DD.MM..YYYY HH24:MI:SS'));


[Geert Bellekens]

Hmm, if this really isn't possible using the API then this is a major problem for all tools written on a configuration like ours. I do not wish to access the database directly (that's what we have an API for). So this actually means that I cannot create any tree-like structure automatically. (so forget template like features, own mda-transformations,....)
I'll wait for a response from sparx support before entering an enhancement request.

[«Midnight»]

Please keep us informed Geert. I too can see this causing all kinds of chaos for a tool. And I agree that tweaking the database is far too fragile to be a production solution.

David

[Geert Bellekens]

After a reminder to Sparx support I got the following answer:

Hello Geert,

Sorry for the delay.

Unfortunately there is no mechanism exposed in the automation interface
at this time for managing locks.

The only way to observe or modify locks would be directly querying the
t_seclocks table.  As you are likely aware - direct querying of the
database can be dangerous and is not officially supported by us, so to
do so would be at your own risk.

We have logged a feature request on your behalf to add lock management
capability to the automation interface, but cannot give any estimate on
when this may be implemented.

Sorry we could not be of more assistance at this time.

[«Midnight»]

Thanks Geert,

Not what I'd hoped to hear, but at least it is (or briefly was) on their horizon.

This one is going to cause some grief, at least where I am concerned.

David

[OilyRag]

Due to this problem, we have had to drop the use of the "Require User Lock To Edit" security policy.

This is because we have add-ins that create package and element structure (eg. when importing package and requirement structure from RequisitePro) and we cannot lock a newly created model element during that processing within the add-in. This is very annoying.

I hope Sparx Systems do something about this.  

[Geert Bellekens]

Another solution could be that they automatically lock all newly created items when the option "Require user lock to edit" is on. That would also avoid some annoyance when creating new packages manually. Now, after creating a new package, you have to lock it first before being able to add or change something to it.

[«Midnight»]

Another solution could be that they automatically lock all newly created items when the option "Require user lock to edit" is on. That would also avoid some annoyance when creating new packages manually. Now, after creating a new package, you have to lock it first before being able to add or change something to it.

...and...

Due to this problem, we have had to drop the use of the "Require User Lock To Edit" security policy.

This is because we have add-ins that create package and element structure (eg. when importing package and requirement structure from RequisitePro) and we cannot lock a newly created model element during that processing within the add-in. This is very annoying.

I hope Sparx Systems do something about this.  

This one is pretty important - at least to the extent that some approach to the issue is needed. Have either of you filed bug reports and received responses from Sparx?

David

[Geert Bellekens]

No haven't filed a bug report as this is in fact not a bug, but just a missing feature.
They did put the issue on the CR list as from my support issue.

[«Midnight»]

I hear you Geert,

I suppose that is the best we can hope for. It's partly how you view this kind of thing. For any given product, some features would be nice, but are not offered. That's the kind of thing that a feature request is for.

But... [Please take all the following in the context of IMHO.]

Sometimes a feature is 'missing' in the sense that it should be there - in the sense that some other set of features offered by the project is rendered incomplete - but simply is not. No, this is not a fault, where the product fails somehow. But it could be considered a bug, in that the offered feature set does not produce optimal results, or cannot be used in (all) the appropriate circumstances.

In the latter case, if the 'missing' feature were actually present and the product performed that way, we'd report the problem as a bug. So in these cases I often take the position that if the overall performance of the product is flawed there is a bug, and the feature in question needs to be added, and working correctly.

David