Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-821

AbstractMETSIngester creates an item before adding descriptive metadata



    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.0
    • Fix Version/s: 1.7.1
    • Component/s: DSpace API
    • Labels:
    • Attachments:
    • Comments:
    • Documentation Status:
      Not Required


      When items are ingested via SWORD (and anything that uses the METS package ingester mechanism), the 'thanks for your submission' email shows the title of the item to be untitled. This has been tracked down to changes made in 1.7 to introduce community and collection AIP restoration in AbstractMETSIngester.java. The item is created before descriptive metadata is added. This means at the time the email is sent, no descriptive metadata has yet been added, hence the 'untitled'.

      IRC log:

      [08:32am] stuartlewis: With all the packager changes in 1.7, has the order of item creation been changed? It looks like items are now created and installed (and therefore 'thanks for your submission' emails are sent), and following that, the package opened and the metadata etc is added to the item. Previously I think it all happened in one go, and the item was created at the end of the process. I think this might be the culprit to Jose's SWORD email problem in dspace-tech.
      [08:35am] tdonohue: hi stuartlewis – yea, i got a minute
      [08:36am] tdonohue: so, can you point me at the code/classes you are looking at? I don't recall this process changing, but maybe that will help
      [08:37am] stuartlewis: AbstractMETSIngester
      [08:37am] stuartlewis: ingestObject method
      [08:38am] tdonohue: just a sec, pulling that up now
      [08:38am] stuartlewis: Just looking for some line numbers
      [08:38am] stuartlewis: Line 429 calls:
      [08:38am] stuartlewis: dso = PackageUtils.createDSpaceObject(context, parent,
      [08:38am] stuartlewis: type, handle, params);
      [08:39am] grahamtriggs: Actually, the offending line would be PackageUtils, Line 477
      [08:39am] grahamtriggs: // Finish creating item with specified handle
      [08:39am] grahamtriggs: // (this will either install item immediately or start a workflow, based on params)
      [08:39am] grahamtriggs: dso = finishCreateItem(context, wsi, handle, params);
      [08:39am] stuartlewis: Yep - was just tracing it through to there.
      [08:39am] stuartlewis: Then it bounces back, and then in Step 5, descriptive metadata is added.
      [08:40am] stuartlewis: So the 'thanks' email is sent before the descriptive metadata has been set.
      [08:40am] stuartlewis: (I think!)
      [08:41am] tdonohue: hmmm...yea, I think you may be right about this. Obviously, wasn't my intention to change that processing...
      [08:41am] tdonohue: i'm digging around more...trying to determine why I did things this way (this was all part of the AIP work, obviously)
      [08:42am] grahamtriggs: you did it to get a DSpaceObject!
      [08:43am] tdonohue: yea, you're right – I needed a DSpaceObject in order to deal with ingest of Community, Collection or Item in a generic fashion.
      [08:43am] tdonohue: unfortunately, WorkspaceItem is not a DSpaceObject, so I needed to obtain one
      [08:44am] tdonohue: (i.e. it's a result of our semi-backwards datamodel, where not everything is a DSpaceObject)
      [08:48am] tdonohue: wait – where is the code that sends the email notifications? why am I not finding that in InstallItem? (sorry, I'm forgetful today)
      [08:48am] tdonohue: nevermind – found it... it's an event
      [08:48am] tdonohue: // Notify interested parties of newly archived Item
      [08:48am] tdonohue: c.addEvent(new Event(Event.INSTALL, Constants.ITEM, item.getID(),
      [08:48am] tdonohue: item.getHandle()));
      [08:50am] tdonohue: so...this is definitely a bug. I'm not sure how best to fix it though off top of my head, as it's unfortunately very specific to Items, and AbstractMETSIngester needs to now support Community & Collection as well.
      [08:51am] stuartlewis: Shall I stick it in JIRA for now?
      [08:51am] tdonohue: definitely put it in JIRA. we need to fix this in 1.7.1, I'd say.
      [08:51am] stuartlewis: OK - will do.
      [08:53am] grahamtriggs: well, WorkspaceItem wraps a DSpaceObject - the storage for anything done in the workspace is the Item itself. So, you ought to be able to treat workspace [items] as DSpaceObjects - whether that is making them one or giving access to the internal object


          Issue Links



              tdonohue Tim Donohue
              stuartlewis Stuart Lewis
              0 Vote for this issue
              0 Start watching this issue