Closed peetucket closed 7 years ago
Note that nothing in the model precludes APOs and Collections from having content since they are at the core simply digital assets, and attachments should be allowed if desired. APOs used to carry their agreements but agreements are now separate objects. Collections we thought might bear thumbnails or other supporting stuff someday, but exhibits took over the anticipated roles of enhancing the metadata for end-user apps. So we don't have any examples in nature right now for non-items with content, and I think that is safe to assume that in the long term, at least for Hydrus objects and leading up to SDR3. Just wanted to share this background.
I think the underlying issue is that the webservice call is made here:
https://github.com/sul-dlss/assembly/blob/master/lib/accessionable.rb#L16-L17
The call goes to dor-services-app and then this line blows up because we have an APO object, and dor-services gem does not define 'initialize_workspace' on APO objects:
https://github.com/sul-dlss/dor-services-app/blob/master/app/controllers/objects_controller.rb#L35
If you look at the following code in dor-services, you will see the 'initialize_workspace' method is defined here:
https://github.com/sul-dlss/dor-services/blob/master/lib/dor/models/concerns/assembleable.rb#L3
Yet that module is only included in the "item" model:
https://github.com/sul-dlss/dor-services/blob/master/lib/dor/models/item.rb#L8
It is not included in collections, sets or APOs. So that method call will now likely fail for anything other than an item (speculation).
Could alternatively be fixed in dor-services-app by checking to see what type of object we have and only calling the method here https://github.com/sul-dlss/dor-services-app/blob/master/app/controllers/objects_controller.rb#L35 if the method is defined for that type of object (currently only items).
However, per Lynn's comment, if it's theoretically possible to have content for collections and APOs, we may want to fix by updating dor-services so that the method is available for all object types (by including the assembleable module in the other object types
Thanks for looking into this @peetucket - it is much appreciated! I think @LynnMcRae would most likely prefer the dor-services update you suggest to include the assembleable module in the other object types because the underlying (theoretical) model of DOR does not preclude any objects having content (i.e. needing the initialize_workspace method). Am I right about that?
That probably makes the most sense, but it would be good to take this to the full infrastructure team since they may have ideas/concerns that are not thinking of.
I am happy with the immediate fix for the Hydrus APOs since the assumptions happen to be true for APOs and Collections in general. My questions concerned the contexts in which the assembly tools might operate and whether this assumptions might not be valid universally and over time. That could be a red herring. We can wait for Ben and others to see how deep a more solid solution might go if needed.
also worth nothing this issue comes up only for objects going through the assemblyWF, which is true of:
So this does exclude some stuff (e.g. with the exception of Hydrus, collections or APOs are created outside these frameworks).
The thing that I have not investigated is what caused this problem to begin at some point in the near past --- presumably it was after some refactoring in the dor-services gem late last year, though that is speculation.
see https://argo.stanford.edu/view/druid:bp848bn2375
It appears the new dor-services-app (using the latest dor-services gem) bombs when the accessioning-initiate robot tries to initialize the workspace. I believe the fix may be to skip the workspace initialization call in the robot for non-item objects.
potential fix in #61