Report or other method to show locked IEs
IEs can be locked due to different reasons. A user may have manually locked an object in Permanent and forgotten to unlock it, or there may be an issue with a hanging or incorrectly aborted processes, causing an IE to be locked by a system process.
Locked objects cause problems in the system, especially when trying to run another process over a locked IE. Currently, there is no available method through which the user can check which IEs are locked. We currently have to open a ticket with support who identifies locked IEs for us.
It would be helpful to have a method (e.g. report) to show which IEs are locked.
I’m happy to let you know that this report was implemented and will be available as part of Rosetta version 5.3.
I'm happy to let you know that this report was implemented and will be available as part of Rosetta version 5.3.
I'm happy to let you know that we will add such a report to an upcoming Rosetta version,
Michelle Lindlar commented
Thanks for the info Jens! Beyond being able to retrieve the state via API we are also looking for a method for "plain" staff users, who strictly work with Rosetta through the UI and not via the API to be able to query for locked IEs. As locked IEs are frequently problematic in scheduled processes it would be helpful for e.g. a data manager or editor to be able to check if any IE belonging to a set is locked before running a process over said set.
From a data management perspective there are several use cases for a query such as "which IEs are currently being working on (i.e. locked)".
Jens Steidl commented
We found out that you can (at least theoretically in an indirect way) test the locking state of a specific IE-PID by using the getMD() and updateMD() API call.
First, use getMD() to get the current descriptive DC metadata and than try to call updateMD() with the same DC metadata.
If the IE is unlocked you get the SOAP faultstring "IE IE...... was not updated. Reason: No change in metadata." (no additional IE version created).
If the IE is locked you get the SOAP faultstring "Cannot Update MD, PID:IE...... since control is locked".
If combined with SRU queries to retrieve all desired IE PIDs, a report could be created.
Maybe this is helpful to you until an API is provided.
I support your idea; I think retrieving the IE state (at any processing stage) via API is a needed feature.