[
https://jira.duraspace.org/browse/DS-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-821:
---------------------------
Attachment: DS-821.patch
Attached a proposed patch which does the following:
* Changes PackageUtils.createDSpaceObject() to just create an Item, but no
longer install it
* Reorganizes the AbstractMETSIngester.ingestObject() method so that
crosswalking of Descriptive Metadata happens *before* adding bitstreams. Also
ensures that after bitstreams are added, the PackageUtils.finishCreateItem()
method is called to actually install the Item.
NOTE: this patch also adds a new WorkspaceItem.findByItem() method which allows
one to locate the WorkspaceItem with just a reference to the Item object. This
is necessary as the PackageIngester workflow deals entirely with DSpaceObjects.
As WorkspaceItem is not a DSpaceObject, we need to pass around the Item
object, and then check whether this Item is related to a WorkspaceItem.
This patch needs more testing! If you have time to help out, I'd appreciate it!
> 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
