How can we improve Rosetta?

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.

11 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Michelle LindlarMichelle Lindlar shared this idea  ·   ·  Admin →

    4 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Michelle LindlarMichelle 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 SteidlJens 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.

      Feedback and Knowledge Base