[
https://jira.duraspace.org/browse/DS-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue resolved DS-821.
----------------------------
Resolution: Fixed
I've tested the above patch both via SWORD ingest and AIP submission. In both
cases, the submission emails now populate properly, as does the
dc.description.provenance information.
Committed above patch to both Trunk (r6136) and 1.7.x branch (r6137).
> AbstractMETSIngester creates an item before adding descriptive metadata
> -----------------------------------------------------------------------
>
> Key: DS-821
> URL: https://jira.duraspace.org/browse/DS-821
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0
> Reporter: Stuart Lewis
> Assignee: Tim Donohue
> Priority: Major
> Fix For: 1.7.1
>
> Attachments: DS-821.patch
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
