Hi Tim, I’m not sure exactly what you mean by “cannot map to a Collection” so not sure if that contradicts my reading (not a Java developer) of the code, which implies groups named “COLLECTION_[id]_ITEM_DEFAULT_READ” may exist, although there are none in our database (historic?). Specifically, the NPE stems from getParentObject() finding policies for the “subject” group (ie the one it was called with, Anonymous in my problem case) for action DEFAULT_ITEM_READ on collections, and then comparing the subject group name with the default item read group name for the collection in each policy (NPE if dspace_object is null) until it finds a match.
It looks like #9190 is relevant to us (sigh), but as far as I can see it is a different issue, although related in that both that and null dspace_object values look like resourcepolicy integrity issues. I agree it looks like there is “messy data” (though not limited to resourcepolicy) in the database. Your warning is understood (and appreciated). I am conscious of potential problems with data migration, but haven’t found any reason to suspect this. 7.6.1 seems to be generally working as expected and the data issues I’ve uncovered so far(!) are evident in the 5.6 database, even if not causing such obvious problems there. Anyway, to (hopefully) add some resolution this thread: after taking a copy of the rows, I executed “delete from resourcepolicy where dspace_object is null;” which has resolved the specific issue, with no apparent ill-effect. Thanks again, Alex From: DSpace Technical Support <[email protected]> Sent: 13 February 2024 20:59 To: DSpace Technical Support <[email protected]> Subject: Re: [dspace-tech] Re: Access control -> Groups stuck "Loading" 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]<http://secure-web.cisco.com/1zylJyr4ck6qj3KoegGnugyCKtRtO2NkrDiochepS1t3uSia1Pzn6qMKxNV0tCLMSEUdkGN_K05MCOFVV63OEEyE67OoK30R-7s4QT4sEkVlJruYVY1za268mMqvkRXvJrLnMkmBptQg_p-juZ73mCZlZ4SAB-ykPjPJ2WnLbtGkk6ejn5kE-ybgLAgcflgl-mvm6bm-YhJUIB_qlwavLKcvwr8NHSr0V-Dt1R0qr4lcz26m-1pPLy_AQZa2YFjlX-g_I4daXVHciOmd2YEIfpLpFdCSI5L2ydjpUprtHVJODJ0xoJ-GZUd4pzRQoT9YJPdM09XEKdNfi2T8LVQNToSHYSHgNtmgjlyJL2G4wAh3BYYY4Qfy9CMErx-Q-gB-V-P6pWlVrzLT6x4pUqOlJPxmxv0RsAcBpsoPbrMuWOYD-qhjUbtXHBcm0oNqDDzV_HidYqePM9TXkxj5gz_n7mfLePqLDOdTe0nS_bBt8w84/l47%3Amailto%3Adspace-tech%2Bunsubscribe%40googlegroups.come>. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/2ebb2042-5d0b-42a0-a033-a838dca7292dn%40googlegroups.com<https://groups.google.com/d/msgid/dspace-tech/2ebb2042-5d0b-42a0-a033-a838dca7292dn%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/LO0P265MB5432DD3E9D3FFC45A7545602CB572%40LO0P265MB5432.GBRP265.PROD.OUTLOOK.COM.
