[dspace-tech] migrate-embargo

[Michael Plate]

Hi folks,

we have a problem on our test-migration from a DSpace 5 to 7.6.1.
Database migration went well, also re-indexing had no problems.



First, we have

embargo.field.terms = ubks.embargo.terms
embargo.field.lift = ubks.embargo.end
embargo.terms.open = forever

in local.cfg

When trying

~/bin/dspace migrate-embargo

this happens


Lifting embargo from Item handle=123456789/12798, lift date=2021-12-31
Lifting embargo from Item handle=123456789/12835, lift date=2021-12-31
Lifting embargo from Item handle=123456789/15050, lift date=2024-01-24

         at org.dspace.embargo.EmbargoCLITool.main(EmbargoCLITool.java:149)

         at java.base/java.lang.reflect.Method.invoke(Method.java:568)









The config of  dspace-angular is identical for dev and prod.
If I run yarn start:dev, I can access an embargoed item just with

<server>/handle/123456789/15596

and it works.



<server>/handle/123456789/15596





[
   MetadataValue {
     uuid: '4d5a200d-38de-476d-b2ed-1d9c5c279ac7',
     language: '',
     value: 'Name, Surename',
     place: 0,
     authority: null,
     confidence: -1
   }
]

GET /items/29128795-d3df-4e55-85e5-5ebd5c60ec84 - - ms - -
1 rules skipped due to selector errors:


(Followed by a proxy error in the browser)

I can
- search for title and the item shows
- search for the handle
- edit as admin

Any ideas, please ?

CU

Michael



--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx

To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/1f0b8484-0a26-478d-a2e6-643118e0eeb5%40bibliothek.uni-kassel.de.

While the system is working mostly :) as expected , migration of the old embargo system refuses to work. Lifting embargo from Item handle=123456789/2018021254576, lift date=2019-02-12 Lifting embargo from Item handle=123456789/2018021554580, lift date=2019-02-15 Checking current embargo on Item handle=123456789/15596, lift date=2025-03-12 ERROR, got exception: java.lang.NullPointerException: Cannot invoke "org.dspace.eperson.EPerson.getFullName()" because the return value of "org.dspace.authorize.ResourcePolicy.getEPerson()" is null java.lang.NullPointerException: Cannot invoke "org.dspace.eperson.EPerson.getFullName()" because the return value of "org.dspace.authorize.ResourcePolicy.getEPerson()" is null at org.dspace.embargo.DefaultEmbargoSetter.checkEmbargo(DefaultEmbargoSetter.java:175) at org.dspace.embargo.EmbargoServiceImpl.checkEmbargo(EmbargoServiceImpl.java:235) at org.dspace.embargo.EmbargoCLITool.processOneItem(EmbargoCLITool.java:209) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:283) at org.dspace.app.launcher.ScriptLauncher.handleScript(ScriptLauncher.java:134) at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:99) When I look into the database, I have policies for the item 123456789/15596 like this 774273 | 2 | 9554 | 0 | | | | TYPE_INHERITED | | | 797a7d58-4393-4b50-906d-32a07c340cc1 | 29128795-d3df-4e55-85e5-5ebd5c60ec84 There are no epersons, only egroups. There are two of them, one is Administrator, the other Anonymous. The access to the bundles is Anonymous, while the access to the bitstreams is Administrator If I run the (yarn build:prod) version by node dist/server/main.js, a direct access by shows the following error on the console where node was started and the request dies: Warning [ERR_HTTP_HEADERS_SENT]: Tried to set headers after they were sent to the client The response for 'https://<server>/server/api/core/items/29128795-d3df-4e55-85e5-5ebd5c60ec84/bundles?size=9999' has the self link 'https://<server>/server/api/core/items/29128795-d3df-4e55-85e5-5ebd5c60ec84/bundles?embed=primaryBitstream&embed=bitstreams/format&embed.size=bitstreams=5&size=1000'. These don't match. This could mean there's an issue with the REST endpoint The response for 'https://<server>/server/api/core/bundles/a010cb0b-2ff2-430c-80c7-9e28b6e10514/bitstreams' has the self link 'https://<server>/server/api/core/bundles/a010cb0b-2ff2-430c-80c7-9e28b6e10514/bitstreams?embed=format'. These don't match. This could mean there's an issue with the REST endpoint The response for 'https://<server>/server/api/core/bundles/1a68cbf2-3fbf-45ab-920b-16553980a4ec/bitstreams' has the self link 'https://<server>/server/api/core/bundles/1a68cbf2-3fbf-45ab-920b-16553980a4ec/bitstreams?embed=format'. These don't match. This could mean there's an issue with the REST endpoint .custom-file-input:lang(en)~.custom-file-label -> unmatched pseudo-class :lang --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.

smime.p7s
Description: Kryptografische S/MIME-Signatur