I can't answer the questions of whether OIA should harvest license files, or whether or not license bitstreams should have a read policy. I can tell you I just spend 2 days fixing this exact issue on our DSpace 6.4 server, and I'm curious if the issue really is no read policy on your license files.
I found this issue: https://jira.duraspace.org/browse/DS-3969 which has a couple of useful SQL queries, specifically the second one: SELECT resource_id, dspace_object FROM resourcepolicy WHERE epersongroup_id IS NULL AND resource_id IS NOT NULL AND resource_type_id=2 GROUP BY 1, 2; Using that query I found a number of "corrupt" items in our repository -- items with no metadata, no bitstreams, but quite a few resource policies. These records could not be modified or deleted via the XMLUI interface, although the resource policies could. They looked as if they may have been some sort of failed submission as there were matching item IDs in the workspace item table. I ended up deleting these records directly from the database using the following commands (I recommend you try and changes on a test server first!!!). in my case these items didn't have bundles or bitstreams, so I didn't need to clean up any additional tables. DELETE FROM public.resourcepolicy WHERE dspace_object='ITEM_ID'; DELETE FROM public.workspaceitem WHERE item_id='ITEM_ID'; DELETE FROM public.metadatavalue WHERE dspace_object_id='ITEM_ID'; DELETE FROM public.item WHERE uuid='ITEM_ID'; Once I cleaned up these corrupt records (specifically removing the invalid policies) my OAI import worked perfectly. So, I'm curious if it's just that you need policies on the license files, or do you perhaps have some bad/corrupt policies? In our case, this was a DSpace 5.4 instance that I just upgraded to 6.x. The OAI import didn't report any issues (that I'm aware of) until the upgrade. - Darryl On Wednesday, October 10, 2018 at 9:09:02 AM UTC-6, Nicholas Woodward wrote: > > On our DSpace 6.3 instance we're seeing an authorization error on the > license.txt bitstreams when we run `oai import`. The license bundles and > bitstreams don't have any authorization policies attached to them. I know > I've seen a few Jira issues related to this issue with code that has been > merged, so I'm a bit confused why it's still happening with our instance. > > > My questions are: should the oai process be harvesting license.txt files > in the first place? Is there some configuration I could add to the XOAI > config that would ignore these bundles? Or do the license.txt bundles > *need* to have authorization policies attached to them? > > > Thanks, > Nick > > > > WARN org.dspace.xoai.util.ItemUtils @ Authorization denied for action > READ on BITSTREAM:[uuid] by user null > org.dspace.authorize.AuthorizeException: Authorization denied for action > READ on BITSTREAM:[uuid] by user null > at > org.dspace.authorize.AuthorizeServiceImpl.authorizeAction(AuthorizeServiceImpl.java:157) > at > org.dspace.authorize.AuthorizeServiceImpl.authorizeAction(AuthorizeServiceImpl.java:95) > at > org.dspace.authorize.AuthorizeServiceImpl.authorizeAction(AuthorizeServiceImpl.java:89) > at > org.dspace.content.BitstreamServiceImpl.retrieve(BitstreamServiceImpl.java:307) > at > org.dspace.xoai.util.ItemUtils.retrieveMetadata(ItemUtils.java:298) > at org.dspace.xoai.app.XOAI.index(XOAI.java:424) > at org.dspace.xoai.app.XOAI.index(XOAI.java:282) > at org.dspace.xoai.app.XOAI.indexAll(XOAI.java:227) > at org.dspace.xoai.app.XOAI.index(XOAI.java:134) > at org.dspace.xoai.app.XOAI.main(XOAI.java:563) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229) > at > org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81) > ERROR org.dspace.xoai.app.XOAI @ > java.lang.NullPointerException > at org.dspace.xoai.app.XOAI.willChangeStatus(XOAI.java:441) > at org.dspace.xoai.app.XOAI.index(XOAI.java:371) > at org.dspace.xoai.app.XOAI.index(XOAI.java:282) > at org.dspace.xoai.app.XOAI.indexAll(XOAI.java:227) > at org.dspace.xoai.app.XOAI.index(XOAI.java:134) > at org.dspace.xoai.app.XOAI.main(XOAI.java:563) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229) > at > org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81) > > > > -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
