Error trying to administer workflows or add an item to collection with certain workflows (same error)

[hading]

Describe the bug In DSpace 7.5, when visiting the /admin/workflow path or trying to add an item via the web interface to items with a certain workflow we receive an error.

To Reproduce I suspect that this is surfaced by our particular submission workflow set up. I do have a specific error from the logs which I'll paste in later. The same error occurs in both cases. We get an error when we either:

1. Use the Administer Workflow link in the sidebar. In the main body under "Workflow and Workspace tasks" we get an error message "Error fetching search results".
2. Go to a collection using a particular one of our submission workflows. Click "New->Item" on the sidebar and select the collection. Under "Your submissions" we get the same error "Error fetching search results".

As far as we can tell the user does have appropriate permissions for these actions.

Expected behavior The admin should be able to either administer the workflows or add an item depending on the case.

Comments

In both cases we see this error in the logs:

2024-02-13 15:18:49,927 ERROR c08671ec-5516-4e4e-af8a-06f07cf1d375 8a592ba6-1126-4746-bd90-5ca305a7ffbd org.dspace.app.rest.exception.DSpaceApiExceptionControllerAdvice @ An exception has occurred (status:500)
java.lang.ClassCastException: class org.dspace.content.Community cannot be cast to class org.dspace.content.Collection (org.dspace.content.Community and org.dspace.content.Collection are in unnamed module of loader org.apache.catalina.loader.ParallelWebappClassLoader @d3957fe)
	at org.dspace.app.util.SubmissionConfigReader.getCollectionsBySubmissionConfig(SubmissionConfigReader.java:631) ~[dspace-api-7.5.jar:7.5]
	at org.dspace.app.rest.converter.SubmissionDefinitionConverter.convert(SubmissionDefinitionConverter.java:84) ~[classes/:7.5]
	at org.dspace.app.rest.converter.SubmissionDefinitionConverter.convert(SubmissionDefinitionConverter.java:39) ~[classes/:7.5]
	at org.dspace.app.rest.converter.ConverterService.toRest(ConverterService.java:112) ~[classes/:7.5]

---

In case 2 if we switch the workflow for the collection to our default workflow then the user is able to proceed, so it appears that perhaps this is tied to the particular submission workflow somehow. In this case I'm changing the submission-name in our submission-map from our custom workflow to the default workflow. Concretely here I'm changing from:

    <name-map collection-handle="10066/344" submission-name="hctheses"/>

to

    <name-map collection-handle="10066/344" submission-name="traditional"/>

---

However, if I leave that the same as it originally was and in the submission-definitions I interchange the values of the name attributes for the traditional and custom submission processes, so now the custom one still has the custom name but the process described by that is now the traditional process, then it still fails, as if it cares explicitly what the name of the process is.

Here I'm leaving

    <name-map collection-handle="10066/344" submission-name="hctheses"/>

But changing

    <submission-process name="hctheses">

to

    <submission-process name="traditional">

and vice-versa, without altering their contents.

[tdonohue]

@hading : The error you shared implies that you may have an incorrect configuration:

java.lang.ClassCastException: class org.dspace.content.Community cannot be cast to class org.dspace.content.Collection
    at org.dspace.app.util.SubmissionConfigReader.getCollectionsBySubmissionConfig(SubmissionConfigReader.java:631)

Looking at that 631 line of code, it appears to be saying that one of your Collection configurations is pointing at a Community.

In other words, you have a config like this:

 <name-map collection-handle="[handle]" submission-name="hctheses"/>

But the [handle] you are pointing at is a Community object and not a Collection.

I think this isn't a bug but a misconfiguration.

[hading]

Thanks Tim.

Here's the item in the wild: https://scholarship.tricolib.brynmawr.edu/handle/10066/344. It certainly appears to be a collection.

Also if it were not, why would I be able to change the submission name attribute to a different submission process without changing the handle and have it start working?

The submission workflows are migrated from earlier DSpace versions, so I had thought perhaps there was something there, especially as we did have to fix up some step definitions.

I should also note for the purposes of completeness that people have reported being able to add to this collection and others using the same submission process via batch processes, it seems like it's only adding individual items via the web interface that is problematic.

Also I'd kind of argue that code that is trying to do a cast that through some circumstances, intended or not, it's not going to be able to do is a bug, so that's why I reported it even though it could ultimately turn out to be a configuration issue. I mean, it may not be one worth the resources to fix, but still a bug. Additionally while searching for info about it there was another issue that was at least superficially similar https://github.com/DSpace/DSpace/issues/8985 that involves a class cast failing that had its roots in how handles were working (incidentally I tried some of the variations on versioning/handles in that ticket as well with no success).

Thanks, Howard

[tdonohue]

@hading : Based on my reading of the code in this area, I don't see how it's possible for that error to occur without the Handle somehow resolving to a Community. Take a look at the code where this occurs and you'll see it's reading every <name-map> entry of the form:

<name-map collection-handle="[handle]" submission-name="[submission-form]"/>

Then it's taking the [handle] and resolving it. It's obviously supposed to be a Collection, but the error is saying that one of your <name-map> entries appears to resolve to a Community?? Are you sure that the error is specific to the object with Handle 10066/344?

I do agree with you that logically the error handling in the code could be improved. I was just trying to point out that this error message appears to be saying it has encountered a Handle to a Community when it expected to find a Collection.

I'm a bit confused then by this entire description. It seems like some information must be missing, cause I don't understand myself how a Collection with Handle 10066/344 would somehow resolve to a Community object in that area of the code.

You may want to investigate further to see if there are prior errors in your logs that provide more clues... or see if you can narrow down the problem to a single Collection or a single configuration.

[hading]

I don't understand either, which is why after a day trying to figure it out I decided to put in a ticket in case there was something clear that I was missing. :-)

I understand even less how some of the modifications I made could fix the problem. I.e. as configured it fails, but the mere act of changing in the config file the submission process for that collection to the default process with no other changes makes the error go away. It's fine then, it just doesn't go through the process we want it to. I can't imagine what the code could be doing that would cause it to seemingly look up a community in the one case but a collection in the other, but my knowledge of the DSpace code is not deep.

To be clear with the example, if I literally make the single change from:

<name-map collection-handle="[handle]" submission-name="[submission-form]"/>

to

<name-map collection-handle="[handle]" submission-name="[other-submission-form]"/>

then it'll go through.

I'll look at it some more, though. Thanks for giving it a look.

[tdonohue]

@hading : For what it's worth, I cannot reproduce this issue locally on my development instance starting with a fresh configuration & simply adding a new form for one Collection. I've also not yet heard of this behavior at any other institution.

It almost seems like behavior caused by a customization on your end or an unexpected configuration. But, if I were in your shoes, I'd recommend looking for other errors in logs. Or check to see if it impacts every Collection. Or even try temporarily reverting all your custom submission configs and start with a "fresh" item-submission.xml and submission-forms.xml and slowly adding your customizations back in to see when it fails.

Basically, I think we're missing something here. None of this makes sense logically from what I know about the DSpace codebase. It might still be a bug, but I don't have enough information to reproduce this in order to figure out why this would be occurring.

[mwoodiupui]

This is probably a tangent, but I recalled running into a problem when there was a mapping configured with a Community handle. FWIW my patch is:

diff --git a/dspace-api/src/main/java/org/dspace/app/util/SubmissionConfigReader.java b/dspace-api/src/main/java/org/dspace/app/util/SubmissionConfigReader.java
index 2120848358..35399fba4e 100644
--- a/dspace-api/src/main/java/org/dspace/app/util/SubmissionConfigReader.java
+++ b/dspace-api/src/main/java/org/dspace/app/util/SubmissionConfigReader.java
@@ -22,6 +22,7 @@ import org.apache.commons.lang3.StringUtils;
 import org.apache.logging.log4j.Logger;
 import org.dspace.content.Collection;
 import org.dspace.content.DSpaceObject;
+import org.dspace.core.Constants;
 import org.dspace.core.Context;
 import org.dspace.handle.factory.HandleServiceFactory;
 import org.dspace.services.factory.DSpaceServicesFactory;
@@ -628,7 +629,12 @@ public class SubmissionConfigReader {
                     DSpaceObject result = HandleServiceFactory.getInstance().getHandleService()
                                                               .resolveToObject(context, handle);
                     if (result != null) {
-                        results.add((Collection) result);
+                        if (!(result instanceof Collection)) {
+                            log.error("{} is a {}, not a Collection",
+                                    handle, Constants.typeText[result.getType()]);
+                        } else {
+                            results.add((Collection) result);
+                        }
                     }
                 }
             }

It doesn't fix the problem, but it does at least tell one where the problem is.