Hi Alex, I did see that you mentioned narrowing down to the "Anonymous" group. However, that explanation didn't make sense to me based on the error you shared (it's possible you have more errors though that show the Anonymous group being impacted). The error you shared seems to imply there **is** a ResourcePolicy issue, but it's related to a Group of the name "COLLECTION_[id]_ITEM_DEFAULT_READ" which cannot map to a Collection. It's possible I'm also misreading things though...(I'm not an expert in every line of code in DSpace)
In general though, I *agree* that there's something fishy going on with your ResourcePolicies. This sounds somewhat related to this other bug report from November: https://github.com/DSpace/DSpace/issues/9190 ... though that ticket is about resource policies with *null* EPerson/Group, and not a null Object. There *is* a possible fix in the works for that issue here: https://github.com/DSpace/DSpace/pull/9191 It's still under review though and I'm not sure if it's the same issue you see, but it's semi-related. Overall, you are correct that a ResourcePolicy should point to an *object*. It sounds like somewhere along the way, some messy data made it's way into your ResourcePolicy table. You could try deleting some of those seemingly invalid rows in that table... but before doing so, I'd recommend ensuring you have a backup (so you can revert those deletions if you delete too much). However, I'll also warn that it's *possible* some of your data didn't upgrade/migrate properly. So, if you are seeing major issues elsewhere in the application (accessing objects, logging in, performing other actions), then that could be a sign the migration didn't work properly. If not, then it could just be some bad data in that ResourcePolicy table. That's my best advice for now. Good luck! Tim On Monday, February 12, 2024 at 2:08:24 PM UTC-6 Alex Fraser (Staff) wrote: > Hi Tim, > > > > Thanks for the reply. The data migration was (intended to be) the process > you linked to, migration to a new server. Both old and new use PostgreSQL > on RHEL. For the database, I created an empty one, created the pgcrypto > extension, populated the database with output from pg_dump on the current > server, and then ran “dspace database migrate ignored” prior to starting > Tomcat. I didn’t notice any problem with the database dump/import (not to > discount the possibility I missed it). > > > > I can’t tell if it’s just my lack of understanding or if you missed where > I wrote that I isolated the problem to the Anonymous group specifically (in > fact that seems to be the only one triggering the error described). I’m not > sure if I’ve followed the code correctly, which led me to suspect > resourcepolicy data, so I may be way off, but I observe: > > > > select count(*) from resourcepolicy where epersongroup_id = (select uuid > from epersongroup where eperson_group_id = 0) and action_id = 10 /* > Constants.DEFAULT_ITEM_READ */ and resource_type_id = 3 /* > Constants.COLLECTION */ and dspace_object is null; > > count > > ------- > > 33 > > > > And it looks to me like this is an inconsistency in the 5.6 database > propagated, probably as intended, through migrations (similar to the other > thread I started, https://groups.google.com/g/dspace-tech/c/K-YWS0GpRmk), > eg: > > > > select count(*) from resourcepolicy rp where rp.epersongroup_id = 0 and > rp.action_id = 10 and rp.resource_type_id = 3 and not exists(select * from > collection where collection_id = rp.resource_id); > > count > > ------- > > 33 > > > > More generally, back in the 7.6.1 database: > > > > select resource_type_id, count(*) from resourcepolicy where dspace_object > is null group by resource_type_id; > > resource_type_id | count > > ------------------+------- > > 6 | 2 > > 3 | 254 > > > > As these represent only a tiny fraction of the ~400k resourcepolicy rows > I’m guessing there should be none. If so, the question of course is how > best to reach that state, but in any case there is still a problem > somewhere, so any further suggestions would be great. > > > > Kind regards, > > Alex > > > > *From:* DSpace Technical Support <[email protected]> > *Sent:* 09 February 2024 17:26 > *To:* DSpace Technical Support <[email protected]> > *Subject:* [dspace-tech] Re: Access control -> Groups stuck "Loading" > > > > Hi Alex, > > > > Here's where that error occurs: > https://github.com/DSpace/DSpace/blob/dspace-7.6.1/dspace-api/src/main/java/org/dspace/content/CollectionServiceImpl.java#L938-L941 > > and it's called from here: > https://github.com/DSpace/DSpace/blob/dspace-7.6.1/dspace-api/src/main/java/org/dspace/eperson/GroupServiceImpl.java#L806 > > > > The error appears to be saying that DSpace has found a group named > "COLLECTION_[id]_ITEM_DEFAULT_READ" which does NOT seem to match with a > corresponding Collection? I.e. the "id" doesn't match the id of any > Collection in your system. > > > > How did you go about this data migration? It almost sounds like either > the groups didn't come over properly... or it could just be that you had a > bunch of old COLLECTION_[id] style groups that were ignored in DSpace 5 but > now causing issues in DSpace 7. If it helps, we do have a migration guide > which some sites have found to be one of the easier ways to migrate from > older versions of DSpace into DSpace 7: > https://wiki.lyrasis.org/display/DSDOC7x/Migrating+DSpace+to+a+new+server > > > Tim > > On Friday, February 9, 2024 at 8:12:39 AM UTC-6 Alex Fraser (Staff) wrote: > > Hi, > > > > Running DSpace 7.6.1 with data migrated from DSpace 5.6, logged in as an > administrator, navigating to Access control -> Groups and then accessing a > specific page appears to be stuck “Loading”. Developer Tools in the browser > shows a 500 status for > /server/api/eperson/groups/search/byMetadata?page=83&size=5&query=&embed=object > > and dspace.log contains: > > > > ERROR e83bd9a9-54f0-485c-888f-28336f741126 > 0b5cb60f-db73-4c0c-9e9d-9c28193b937f > org.dspace.app.rest.exception.DSpaceApiExceptionControllerAdvice @ An > exception has occurred (status:500) > > java.lang.NullPointerException: Cannot invoke > "org.dspace.content.Collection.getID()" because "collection" is null > > at > org.dspace.content.CollectionServiceImpl.getDefaultReadGroupName(CollectionServiceImpl.java:939) > > ~[dspace-api-7.6.1.jar:7.6.1] > > at > org.dspace.eperson.GroupServiceImpl.lambda$getParentObject$0(GroupServiceImpl.java:806) > > ~[dspace-api-7.6.1.jar:7.6.1] > > at > java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178) > ~[?:?] > > at > java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1602) > ~[?:?] > > at > java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:129) > > ~[?:?] > > at > java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:527) > > ~[?:?] > > at > java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513) ~[?:?] > > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) > ~[?:?] > > at > java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150) ~[?:?] > > at > java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?] > > at > java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:647) > ~[?:?] > > at > org.dspace.eperson.GroupServiceImpl.getParentObject(GroupServiceImpl.java:807) > > ~[dspace-api-7.6.1.jar:7.6.1] > > at > org.dspace.eperson.GroupServiceImpl.getParentObject(GroupServiceImpl.java:66) > ~[dspace-api-7.6.1.jar:7.6.1] > > at > org.dspace.app.rest.repository.GroupParentObjectLinkRepository.getParentObject(GroupParentObjectLinkRepository.java:63) > > ~[classes/:7.6.1] > > at > org.dspace.app.rest.repository.GroupParentObjectLinkRepository$$FastClassBySpringCGLIB$$abe50bf3.invoke(<generated>) > > ~[classes/:7.6.1] > > (and so on) > > > > After some experimentation I narrowed down the 500 response to the > Anonymous group, and it only happens with “embed=object”. I assume there is > something problematic with the migrated data (I don’t see the issue with a > fresh install), but I’ve been unable to work out what it could be. Any > pointers in the right direction would be gratefully received. > > > > Thanks, > > Alex > > -- > All messages to this mailing list should adhere to the Code of Conduct: > https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx > --- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dspace-tech/d282488d-73f9-434c-bd47-e5a48120f534n%40googlegroups.com > > <https://groups.google.com/d/msgid/dspace-tech/d282488d-73f9-434c-bd47-e5a48120f534n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/2ebb2042-5d0b-42a0-a033-a838dca7292dn%40googlegroups.com.
