[dspace-tech] Re: DSpace 7.6.1 and Deepgreen: SWORD v2 Deposit via METSMODS packaging?

[Matthias Letsch]

Additional information: The deposit via console works just fine with 
METSDSpaceSIP, but this packaging type doesn't seem to work with the 
DeepGreen client...

Matthias Letsch schrieb am Mittwoch, 19. Juni 2024 um 10:51:45 UTC+2:

> Hi there,
>
> This question is primarily aimed at my colleagues from Germany who 
> participate in DeepGreen (https://info.oa-deepgreen.de) and/or people who 
> are familiar with the Swordv2 API...
>
> We're part of DeepGreen and want to deposit the articles via the SWORD v2 
> interface. In DSpace, SWORD v2 is enabled and the deposit works in 
> principle, e.g. via console commands.
>
> I was told to use the method http://purl.org/net/sword/package/METSMODS 
> in the DeepGreen Sword Client. Also, all other details are correct (SWORD 
> username, password, collection). Still the deposit doesn't work. 
>
> When trying to deposit an example via the console, an error message tells 
> me that there is no ingester configured for METSMODS:
> (#=password)
>
> curl -i --data-binary "@example.zip" -H "Content-Disposition:attachment; 
> filename=example.zip" -H "Content-Type:application/zip" -H "Packaging:
> http://purl.org/net/sword/package/METSMODS; -u us...@hohpublica.de:# 
> -X POST 
> https://hohpublica.uni-hohenheim.de/server/swordv2/collection/123456789/15867
>
> Result:
>
> HTTP/1.1 100 Continue
>
> HTTP/1.1 415 415
> Date: Wed, 19 Jun 2024 08:24:20 GMT
> Server: Apache/2.4.38 (Debian)
> Content-Language: en,de
> Content-Type: text/xml;charset=UTF-8
> Transfer-Encoding: chunked
>
> 
> http://purl.org/net/sword/error/ErrorContent; 
> xmlns:sword="http://purl.org/net/sword/terms/;>http://www.w3.org/2005/Atom;>ERRORhttp://www.w3.org/2005/Atom;>2024-06-19T10:24:20Z  
> uri="http://www.dspace.org/ns/sword/2.0/; version="2.0" xmlns:atom="
> http://www.w3.org/2005/Atom;>us...@uni-hohenheim.deProcessing
>  
> failedhttp://www.w3.org/2005/Atom;>No ingester configured for this package 
> typeorg.swordapp.server.SwordError: 
> No ingester configured for this package type
> at ...
>
> It seems like there is no ingester for METSMODS in DSpace 7...
>
> Is there anyone for whom the deposit from Deepgreen SWORD v2 to DSpace 7 
> already works? What do I have to configure so that the deposit works via 
> the specified packaging?
>
> Thank you and kind regards,
> Matthias
>
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/983847be-13cf-4133-89c9-ff7e866eca30n%40googlegroups.com.

[dspace-tech] DSpace 7.6.1 and Deepgreen: SWORD v2 Deposit via METSMODS packaging?

[Matthias Letsch]

Hi there,

This question is primarily aimed at my colleagues from Germany who 
participate in DeepGreen (https://info.oa-deepgreen.de) and/or people who 
are familiar with the Swordv2 API...

We're part of DeepGreen and want to deposit the articles via the SWORD v2 
interface. In DSpace, SWORD v2 is enabled and the deposit works in 
principle, e.g. via console commands.

I was told to use the method http://purl.org/net/sword/package/METSMODS in 
the DeepGreen Sword Client. Also, all other details are correct (SWORD 
username, password, collection). Still the deposit doesn't work. 

When trying to deposit an example via the console, an error message tells 
me that there is no ingester configured for METSMODS:
(#=password)

curl -i --data-binary "@example.zip" -H "Content-Disposition:attachment; 
filename=example.zip" -H "Content-Type:application/zip" -H 
"Packaging:http://purl.org/net/sword/package/METSMODS; -u 
u...@hohpublica.de:# -X POST 
https://hohpublica.uni-hohenheim.de/server/swordv2/collection/123456789/15867

Result:

HTTP/1.1 100 Continue

HTTP/1.1 415 415
Date: Wed, 19 Jun 2024 08:24:20 GMT
Server: Apache/2.4.38 (Debian)
Content-Language: en,de
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked


http://purl.org/net/sword/error/ErrorContent; 
xmlns:sword="http://purl.org/net/sword/terms/;>http://www.w3.org/2005/Atom;>ERRORhttp://www.w3.org/2005/Atom;>2024-06-19T10:24:20Zhttp://www.dspace.org/ns/sword/2.0/; version="2.0" 
xmlns:atom="http://www.w3.org/2005/Atom;>u...@uni-hohenheim.deProcessing
 
failedhttp://www.w3.org/2005/Atom;>No ingester configured for this 
package 
typeorg.swordapp.server.SwordError: 
No ingester configured for this package type
at ...

It seems like there is no ingester for METSMODS in DSpace 7...

Is there anyone for whom the deposit from Deepgreen SWORD v2 to DSpace 7 
already works? What do I have to configure so that the deposit works via 
the specified packaging?

Thank you and kind regards,
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/1b6c08b6-e098-4fd2-aff9-87d2c138ae95n%40googlegroups.com.

[dspace-tech] Re: DSpace 7.6.1 ORCID integration / Synchronization settings ERROR

[Matthias Letsch]

Perhaps for completeness: My user is already in the Submitters Role group 
for Collection "Publications", to which the corresponding publication 
entity is assigned.

Matthias Letsch schrieb am Donnerstag, 13. Juni 2024 um 17:32:17 UTC+2:

> Hello there,
>
> I managed to activate ORCID integration in a test environment with 
> connection to the ORCID sandbox api. (I'm only interested in the Profile 
> and synchronization part, not the ORCID authentication method). 
> Unfortunately, when I try to update ORCID synchronization settings, I get a 
> error message.
>
> *So what I did:*
> 1. Enable configurable entities (
> https://wiki.lyrasis.org/display/DSDOC7x/Configurable+Entities) and 
> Enable Researcher profiles (
> https://wiki.lyrasis.org/display/DSDOC7x/Researcher+Profiles)
> 2. Get ORCID sandbox credentials (
> https://info.orcid.org/documentation/integration-guide/sandbox-testing-server/)
>  
> and enable ORCID integration by setting properties in local.cfg / 
> modules/orcid.cfg (
> https://wiki.lyrasis.org/display/DSDOC7x/ORCID+Integration)
> 3. Log in as test person, claim an existing Person entity as Researcher 
> Profile, connect the profile to sandbox orcid id. <-- Everything worked so 
> far.
>
> *The DSpace ORCID page now states the following: *
> Granted Authorizations: Get your ORCID ID
> Missing authorizations: " Great! This box is empty, so you have granted 
> all access rights to use all functions offers by your institution."
>
>
> *The Error*When changing values in ORCID Synchronization settings and 
> clicking on "Update settings", an error message appears "The update of the 
> synchronization settings failed"
>
> The dspace logs tell me the following:
> 2024-06-13 17:20:41,332 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
> 2024-06-13 17:20:41,363 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
> 2024-06-13 17:20:41,369 INFO  f70163a4-0bc1-4d1d-a361-1601ecfd846b 
> 98ac4304-eeaf-4c3c-96ba-3d575a332afb 
> org.dspace.app.rest.utils.DSpaceAPIRequestLoggingFilter @ Before request 
> [GET /server/api/eperson/profiles/6edd60e9-9457-4ec7-91a0-cbaefec205e2] 
> originated from /entities/person/08715eca-330f-4798-91e6-91a476dafce7
> /orcid
> 2024-06-13 17:20:41,501 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
> 2024-06-13 17:20:41,532 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
> 2024-06-13 17:20:41,546 INFO  f70163a4-0bc1-4d1d-a361-1601ecfd846b 
> b945ba4b-b7e8-46e4-8a6f-3d28184cc02a 
> org.dspace.app.rest.utils.DSpaceAPIRequestLoggingFilter @ Before request 
> [PATCH /server/api/eperson/profiles/6edd60e9-9457-4ec7-91a0-cbaefec205e2] 
> originated from /entities/person/08715eca-330f-4798-91e6-91a476dafce7
> /orcid
>
>
> This ID belongs to the user with whom I am testing the Orcid link and want 
> to update the settings. So that reads as follows for me: Users who link 
> their profile to ORCID need certain rights to at least one collection or 
> community for the ORCID synchronization to work. Do I understand that 
> correctly?
>
> As an admin, how do I assign these rights to users? Can I automate this or 
> do I have to manually give each user with an ORCID link rights to a 
> collection? I don't quite understand this yet. Does anyone have any 
> experience with ORCID integration and can help me here?
>
> Many thanks and best regards
> Matthias
>
>
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/40636be8-0204-4fab-b3b9-d0ee5d7860cdn%40googlegroups.com.

[dspace-tech] DSpace 7.6.1 ORCID integration / Synchronization settings ERROR

[Matthias Letsch]

Hello there,

I managed to activate ORCID integration in a test environment with 
connection to the ORCID sandbox api. (I'm only interested in the Profile 
and synchronization part, not the ORCID authentication method). 
Unfortunately, when I try to update ORCID synchronization settings, I get a 
error message.

*So what I did:*
1. Enable configurable entities 
(https://wiki.lyrasis.org/display/DSDOC7x/Configurable+Entities) and Enable 
Researcher profiles 
(https://wiki.lyrasis.org/display/DSDOC7x/Researcher+Profiles)
2. Get ORCID sandbox credentials 
(https://info.orcid.org/documentation/integration-guide/sandbox-testing-server/)
 
and enable ORCID integration by setting properties in local.cfg / 
modules/orcid.cfg 
(https://wiki.lyrasis.org/display/DSDOC7x/ORCID+Integration)
3. Log in as test person, claim an existing Person entity as Researcher 
Profile, connect the profile to sandbox orcid id. <-- Everything worked so 
far.

*The DSpace ORCID page now states the following: *
Granted Authorizations: Get your ORCID ID
Missing authorizations: " Great! This box is empty, so you have granted all 
access rights to use all functions offers by your institution."


*The Error*When changing values in ORCID Synchronization settings and 
clicking on "Update settings", an error message appears "The update of the 
synchronization settings failed"

The dspace logs tell me the following:
2024-06-13 17:20:41,332 WARN  unknown unknown 
org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
administrable collection or community!
2024-06-13 17:20:41,363 WARN  unknown unknown 
org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
administrable collection or community!
2024-06-13 17:20:41,369 INFO  f70163a4-0bc1-4d1d-a361-1601ecfd846b 
98ac4304-eeaf-4c3c-96ba-3d575a332afb 
org.dspace.app.rest.utils.DSpaceAPIRequestLoggingFilter @ Before request 
[GET /server/api/eperson/profiles/6edd60e9-9457-4ec7-91a0-cbaefec205e2] 
originated from /entities/person/08715eca-330f-4798-91e6-91a476dafce7/orcid
2024-06-13 17:20:41,501 WARN  unknown unknown 
org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
administrable collection or community!
2024-06-13 17:20:41,532 WARN  unknown unknown 
org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
administrable collection or community!
2024-06-13 17:20:41,546 INFO  f70163a4-0bc1-4d1d-a361-1601ecfd846b 
b945ba4b-b7e8-46e4-8a6f-3d28184cc02a 
org.dspace.app.rest.utils.DSpaceAPIRequestLoggingFilter @ Before request 
[PATCH /server/api/eperson/profiles/6edd60e9-9457-4ec7-91a0-cbaefec205e2] 
originated from /entities/person/08715eca-330f-4798-91e6-91a476dafce7/orcid


This ID belongs to the user with whom I am testing the Orcid link and want 
to update the settings. So that reads as follows for me: Users who link 
their profile to ORCID need certain rights to at least one collection or 
community for the ORCID synchronization to work. Do I understand that 
correctly?

As an admin, how do I assign these rights to users? Can I automate this or 
do I have to manually give each user with an ORCID link rights to a 
collection? I don't quite understand this yet. Does anyone have any 
experience with ORCID integration and can help me here?

Many thanks and best regards
Matthias


-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/ddd09eed-5daf-438f-b4e7-657b68d9a173n%40googlegroups.com.

Re: [dspace-tech] DSpace 7.6.1 ORCID integration / Synchronization settings ERROR

[Matthias Letsch]

Hi Sean,

great! That was it. Thank you!

I also had to change the scope to 
orcid.scope = /activities/update
in order to get publications pushed to orcid.

Kind regards,
Matthias

Sean Kalynuk schrieb am Donnerstag, 13. Juni 2024 um 17:47:43 UTC+2:

> Hi Matthias,
>
>  
>
> Regarding the error “The update of the synchronization settings failed”, 
> this has been documented as part the following issue:
>
>  
>
> https://github.com/DSpace/DSpace/issues/8925
>
>  
>
> Locally, I applied the source code fix as described in a comment from that 
> issue https://github.com/DSpace/DSpace/issues/8925#issuecomment-1617623431 
> and it resolved that particular problem for us (at least it did with 7.5).
>
>  
>
> -- 
>
> Sean
>
>  
>
> *From: *dspac...@googlegroups.com  on behalf 
> of Matthias Letsch 
> *Date: *Thursday, June 13, 2024 at 10:32 AM
> *To: *DSpace Technical Support 
> *Subject: *[dspace-tech] DSpace 7.6.1 ORCID integration / Synchronization 
> settings ERROR
>
> *Caution!* This message was sent from outside the University of Manitoba.
>
>  
>
> Hello there,
>
>  
>
> I managed to activate ORCID integration in a test environment with 
> connection to the ORCID sandbox api. (I'm only interested in the Profile 
> and synchronization part, not the ORCID authentication method). 
> Unfortunately, when I try to update ORCID synchronization settings, I get a 
> error message.
>
> *So what I did:*
> 1. Enable configurable entities (
> https://wiki.lyrasis.org/display/DSDOC7x/Configurable+Entities) and 
> Enable Researcher profiles (
> https://wiki.lyrasis.org/display/DSDOC7x/Researcher+Profiles)
>
> 2. Get ORCID sandbox credentials (
> https://info.orcid.org/documentation/integration-guide/sandbox-testing-server/)
>  
> and enable ORCID integration by setting properties in local.cfg / 
> modules/orcid.cfg (
> https://wiki.lyrasis.org/display/DSDOC7x/ORCID+Integration)
>
> 3. Log in as test person, claim an existing Person entity as Researcher 
> Profile, connect the profile to sandbox orcid id. <-- Everything worked so 
> far.
>
>
> *The DSpace ORCID page now states the following: *
> Granted Authorizations: Get your ORCID ID
> Missing authorizations: " Great! This box is empty, so you have granted 
> all access rights to use all functions offers by your institution."
>
>
> *The Error *When changing values in ORCID Synchronization settings and 
> clicking on "Update settings", an error message appears "The update of the 
> synchronization settings failed"
>
> The dspace logs tell me the following:
>
> 2024-06-13 17:20:41,332 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
>
> 2024-06-13 17:20:41,363 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
>
> 2024-06-13 17:20:41,369 INFO  f70163a4-0bc1-4d1d-a361-1601ecfd846b 
> 98ac4304-eeaf-4c3c-96ba-3d575a332afb 
> org.dspace.app.rest.utils.DSpaceAPIRequestLoggingFilter @ Before request 
> [GET /server/api/eperson/profiles/6edd60e9-9457-4ec7-91a0-cbaefec205e2] 
> originated from /entities/person/08715eca-330f-4798-91e6-91a476dafce7
> /orcid
>
> 2024-06-13 17:20:41,501 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
>
> 2024-06-13 17:20:41,532 WARN  unknown unknown 
> org.dspace.discovery.SolrServiceImpl @ We have a collection or community 
> admin with ID: 6edd60e9-9457-4ec7-91a0-cbaefec205e2 without any 
> administrable collection or community!
>
> 2024-06-13 17:20:41,546 INFO  f70163a4-0bc1-4d1d-a361-1601ecfd846b 
> b945ba4b-b7e8-46e4-8a6f-3d28184cc02a 
> org.dspace.app.rest.utils.DSpaceAPIRequestLoggingFilter @ Before request 
> [PATCH /server/api/eperson/profiles/6edd60e9-9457-4ec7-91a0-cbaefec205e2] 
> originated from /entities/person/08715eca-330f-4798-91e6-91a476dafce7
> /orcid
>
>  
>
>
> This ID belongs to the user with whom I am testing the Orcid link and want 
> to update the settings. So that reads as follows for me: Users who link 
> their profile to ORCID need certain rights to at least one collection or 
> community for the ORCID synchronization to work. Do I understand that 
> correctly?
>
> As an admin, how do I assign these rights to users? Can I automate this or 
> do I have to manually 

[dspace-tech] deactivate submit task mail when returning item to pool

[Matthias Letsch]

Hello there,

Is there a way to disable the automatic mail notification of a new task 
when someone returns an item to the pool? So that the mail only comes once, 
namely when the item is newly submitted via the submission form, but not 
every time it is returned to the pool. We only have two colleagues 
responsible for checking, so the repeated emails for the same item are more 
"spam" than helpful.

Thank you and kind regards,
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/a1b779a0-b1ca-492b-9a27-83f338048157n%40googlegroups.com.

[dspace-tech] Dspace 7.6.1 Shibboleth logout is no complete logout

[Matthias Letsch]

Hello there,

when logging out, the Shibboleth sessions seem to be not deleted correctly. 
If you go to Log in again after logging out, you do not have to log in to 
the IdP again. If a login attempt is made in the same browser session with 
a different authentication method, e.g. email + password, after logging 
out, the previous user logs in again via Shibboleth instead of the new one. 
The logout process therefore only seems to delete the sessions of the 
application itself and not those of shibboleth.

Is this a normal/desirable behavior? Is there a way to configure DSpace so 
that the shibboleth session is closed for good or that you land on an 
existing local logout link of the identity provider after logout?

Thank you and kind regards
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/0c769f24-a339-473a-ac96-60458c1ab2b9n%40googlegroups.com.

[dspace-tech] DSpace 7.6.1 Enable Dokuwiki next to DSpace on same Server on Subpage /wiki

[Matthias Letsch]

Hello there,

I am currently testing the possibility of providing a wiki (Dokuwiki) on 
the same server to accompany our DSpace. 

The wiki is stored on the DSpace path under /home/dspace/dspace-wiki/wiki, 
and thus next to the DSpace backend folder /home/dspace/dspace-backend/

I have added an alias for /wiki in the Apache2 configuration:

Alias /wiki /home/dspace/dspace-wiki/wiki

Options +FollowSymLinks
AllowOverride All
Require all granted


Also a rewrite condition:
RewriteCond %{REQUEST_URI} !^/wiki/.*$ [NC]

However, when I call the page [DSpace-URL]/wiki, I still end up on a 404 
page within the Angular front end of DSpace, i.e. Angular is still trying 
to process the subpage, which is outside the Angular framework. 

(With /server/oai, for example, it is my understanding that the page is 
accessed outside of Angular)

By any chance, does anyone have experience with setting up a service in 
parallel to DSpace on the same server and can help me with what I'm missing 
here or what I need to set in order to reach the wiki start page under 
/wiki via the browser?

Thank you and kind regards
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/b3f55b48-9f35-4fe4-b04e-1e0d55387e3dn%40googlegroups.com.

[dspace-tech] Re: DSpace 7.6.1 How to make search work with AND operator instead of OR

[Matthias Letsch]

Thanks, I know I can do a search with quotes to get the exact string, but 
that's not what I want to accomplish. 

I just want a search for multiple terms to return hits that contain all 
those terms and not just one, regardless of their order in it.

Kind regards
Matthias

Maruan Sahyoun schrieb am Freitag, 12. April 2024 um 16:52:07 UTC+2:

> Did you try putting the string in quotes?
>
> BR
> Maruan
>
> Matthias Letsch schrieb am Freitag, 12. April 2024 um 16:18:34 UTC+2:
>
>> Just for the sake of completeness: Unfortunately, our search does not 
>> work as documented here: 
>> https://wiki.lyrasis.org/display/DSDOC7x/Search+-+Advanced
>>
>> It says here that "Basic searching" corresponds to an AND search, but 
>> unfortunately this is not the case with us...
>>
>> Matthias Letsch schrieb am Freitag, 12. April 2024 um 16:10:58 UTC+2:
>>
>>> Hello there,
>>>
>>> Our quick search form on the homepage and in the navigation bar ist 
>>> working with a boolean OR operator by default. For example, if I enter the 
>>> string "Adaptation of model organisms", I get a hit list with over 700 hits 
>>> because every single entry is listed that contains any of the words 
>>> "adaptation" OR "of" (!) OR "model" OR "organisms" in any indexed metadata 
>>> field. I know that there is a publication with a title beginnig exactly 
>>> with this string, but that hit is not at the top, but hidden somewhere in 
>>> the middle of a list of otherwise not relevant hits.
>>>
>>> I personally don't find this useful and I don't know who does. When I 
>>> enter a bunch of words in a "quick search" form, I want exactly the results 
>>> that contain ALL the terms entered - the results of a search with an AND 
>>> operator. An OR search should only be available, if at all, as an advanced 
>>> search option that the user consciously selects.
>>>
>>> So where can I change the behavior of the search and set it accordingly?
>>>
>>> Thank you and kind regards
>>> Matthias
>>>
>>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/3aa1fcf9-4d8c-4fc1-9ab4-aee0f8412363n%40googlegroups.com.

[dspace-tech] Re: DSpace 7.6.1 How to make search work with AND operator instead of OR

[Matthias Letsch]

Just for the sake of completeness: Unfortunately, our search does not work 
as documented here: 
https://wiki.lyrasis.org/display/DSDOC7x/Search+-+Advanced

It says here that "Basic searching" corresponds to an AND search, but 
unfortunately this is not the case with us...

Matthias Letsch schrieb am Freitag, 12. April 2024 um 16:10:58 UTC+2:

> Hello there,
>
> Our quick search form on the homepage and in the navigation bar ist 
> working with a boolean OR operator by default. For example, if I enter the 
> string "Adaptation of model organisms", I get a hit list with over 700 hits 
> because every single entry is listed that contains any of the words 
> "adaptation" OR "of" (!) OR "model" OR "organisms" in any indexed metadata 
> field. I know that there is a publication with a title beginnig exactly 
> with this string, but that hit is not at the top, but hidden somewhere in 
> the middle of a list of otherwise not relevant hits.
>
> I personally don't find this useful and I don't know who does. When I 
> enter a bunch of words in a "quick search" form, I want exactly the results 
> that contain ALL the terms entered - the results of a search with an AND 
> operator. An OR search should only be available, if at all, as an advanced 
> search option that the user consciously selects.
>
> So where can I change the behavior of the search and set it accordingly?
>
> Thank you and kind regards
> Matthias
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/82de881f-0e95-4b43-b835-fb085d3b0a9dn%40googlegroups.com.

[dspace-tech] DSpace 7.6.1 How to make search work with AND operator instead of OR

[Matthias Letsch]

Hello there,

Our quick search form on the homepage and in the navigation bar ist working 
with a boolean OR operator by default. For example, if I enter the string 
"Adaptation of model organisms", I get a hit list with over 700 hits 
because every single entry is listed that contains any of the words 
"adaptation" OR "of" (!) OR "model" OR "organisms" in any indexed metadata 
field. I know that there is a publication with a title beginnig exactly 
with this string, but that hit is not at the top, but hidden somewhere in 
the middle of a list of otherwise not relevant hits.

I personally don't find this useful and I don't know who does. When I enter 
a bunch of words in a "quick search" form, I want exactly the results that 
contain ALL the terms entered - the results of a search with an AND 
operator. An OR search should only be available, if at all, as an advanced 
search option that the user consciously selects.

So where can I change the behavior of the search and set it accordingly?

Thank you and kind regards
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/34724e14-77a1-41fd-80ab-608142a336f9n%40googlegroups.com.

Re: [dspace-tech] DSpace 7.6.1: Switch to myDSpace page directly after login?

[Matthias Letsch]

Hi Sascha,

thank you, this solution works fine for all users that login with email + 
password (authentication-password).

In addition to this authentication method, we have also activated 
shibboleth, which most users will use to log in. Unfortunately, the 
redirect to /mydspace is not executed with the suggested change for those 
users. Do you happen to know whether and which other place needs to be 
changed for this?

Thanks again
Matthias

Sascha Szott schrieb am Donnerstag, 28. März 2024 um 10:13:19 UTC+1:

> Hi Matthias,
>
> we have solved this by adapting one line in
>
> src/app/core/auth/auth.effects.ts
>
> You need to change the implementation of the redirectAfterLoginSuccess$ 
> method by replacing
>
> this.authService.navigateToRedirectUrl(action.payload);
>
> with
>
>
> this.authService.navigateToRedirectUrl('/mydspace');
>
>
> Best regards
> Sascha
>
>
> Am 15.03.24 um 15:51 schrieb Matthias Letsch:
> > Hello there,
> > 
> > By default, you remain on the homepage when you log in. Is there a 
> > (simple) way to set that after logging in you are taken directly to the 
> > myDSpace page with the overview of your own releases?
> > 
> > Thank you and kind regards,
> > Matthias
> > 
> > -- 
> > All messages to this mailing list should adhere to the Code of Conduct: 
> > https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx 
> > <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 dspace-tech...@googlegroups.com 
> > <mailto:dspace-tech...@googlegroups.com>.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/dspace-tech/9dab0f73-5615-49da-84ac-3ce7fbc21b98n%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/dspace-tech/9dab0f73-5615-49da-84ac-3ce7fbc21b98n%40googlegroups.com?utm_medium=email_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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/f356456b-b79d-4058-b489-71452d6f4797n%40googlegroups.com.

[dspace-tech] DSpace 7.6.1: Switch to myDSpace page directly after login?

[Matthias Letsch]

Hello there,

By default, you remain on the homepage when you log in. Is there a (simple) 
way to set that after logging in you are taken directly to the myDSpace 
page with the overview of your own releases? 

Thank you and kind regards,
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/9dab0f73-5615-49da-84ac-3ce7fbc21b98n%40googlegroups.com.

Re: [dspace-tech] Shibboleth vs. IP Group mapping: Conflicting group mappings from different authentication methods

[Matthias Letsch]

Hi Ed,

thank you for your reply!

I'll look at the workaround in detail when I get a chance, but for now I've 
made it easy for myself and simply added a second line to the 
authentication-ip:
authentication-ip.Internal\ Bitstream\ Read = ...
authentication-ip.Submitters = ...

This means that "in principle" you also get a group membership for 
submitters in the campus network, even if you are not logged in, BUT you 
can only open the mask when you are logged in anyway (If you try to open 
the URL to the submission form without logging in, you are automatically 
redirected to the login page). 

So, since we have one central administration and no epersons that are 
explicitly NOT supposed to access the submission form, this works quite 
well for us.

Kind regards,
Matthias 
Hill,Ed schrieb am Dienstag, 12. März 2024 um 19:01:34 UTC+1:

> Hi Matthias,
>
> Unfortunately I don't have any (good) help, but we noticed this too and 
> filed an issue at https://github.com/DSpace/DSpace/issues/9226 
> <https://github.com/DSpace/DSpace/issues/9226>. If you have any extra 
> information to share to what we mentioned you can add it there as well.
>
> Our temporary workaround was to remove the if condition surrounding the 
> code on lines 187 and 188 of 
> https://github.com/DSpace/DSpace/blob/main/dspace-api/src/main/java/org/dspace/authenticate/AuthenticationServiceImpl.java
>  before 
> building our backend. This removes the benefits of a recent bugfix 
> regarding authentication methods (
> https://github.com/DSpace/DSpace/pull/9130), but in our context it was 
> worth it because we needed Shibboleth and IP-based special groups to work 
> in tandem and a more robust fix was not in the cards for us at the time.
>
> I'm happy to talk more off-list about what we specifically did to make 
> this work with our 7.6.1 instance.
>
> Cheers,
>
> Ed Hill 
>
> *Pronouns: He/Him*  (pronoun statement <https://pronouns.colostate.edu/>) 
>
> Developer and Applications Administrator 
>
> (970) 491-3197 
>
> *Colorado State University Libraries *
>
>  
>
> --
> *From:* dspac...@googlegroups.com  on behalf 
> of Matthias Letsch 
> *Sent:* Tuesday, March 12, 2024 10:02 AM
> *To:* DSpace Technical Support 
> *Subject:* [dspace-tech] Shibboleth vs. IP Group mapping: Conflicting 
> group mappings from different authentication methods 
>  
>
> *** Caution: EXTERNAL Sender ***
> Hello,
>
> 1. We have Shibboleth enabled and all epersons logging in via Shibboleth 
> are mapped to the group "Submitters" which gives access to our submission 
> form.
>
> authentication-shibboleth.default-roles = Submitters
>
> 2. We also have some items which should only be accessible in our campus 
> network. Therefore IP authentication is activated with a mapping to the 
> "Internal Bitstream Read" group:
> authentication-ip.Internal\ Bitstream\ Read = ...
>
> Now, if both authentication methods are activated and a person newly 
> registered via shibboleth which also happens to be in the campus network, 
> the eperson no longer receives the Submitters group, but only the Internal 
> Bitstream Read group. 
>
> If I deactivate authentication-ip, the eperson receives the Submitters 
> group again. The aim should be that the eperson is assigned to both groups 
> when both methods are activated. How is this possible?
>
> Thank you and kind regards,
> Matthias
>
> -- 
> 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 dspace-tech...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dspace-tech/b42a5033-532e-4b7d-a2d4-2760a8ae37dfn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/dspace-tech/b42a5033-532e-4b7d-a2d4-2760a8ae37dfn%40googlegroups.com?utm_medium=email_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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/9df4a1fe-189a-4799-b7ab-5843dde70a37n%40googlegroups.com.

[dspace-tech] Shibboleth vs. IP Group mapping: Conflicting group mappings from different authentication methods

[Matthias Letsch]

Hello,

1. We have Shibboleth enabled and all epersons logging in via Shibboleth 
are mapped to the group "Submitters" which gives access to our submission 
form.

authentication-shibboleth.default-roles = Submitters

2. We also have some items which should only be accessible in our campus 
network. Therefore IP authentication is activated with a mapping to the 
"Internal Bitstream Read" group:
authentication-ip.Internal\ Bitstream\ Read = ...

Now, if both authentication methods are activated and a person newly 
registered via shibboleth which also happens to be in the campus network, 
the eperson no longer receives the Submitters group, but only the Internal 
Bitstream Read group. 

If I deactivate authentication-ip, the eperson receives the Submitters 
group again. The aim should be that the eperson is assigned to both groups 
when both methods are activated. How is this possible?

Thank you and kind regards,
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/b42a5033-532e-4b7d-a2d4-2760a8ae37dfn%40googlegroups.com.

[dspace-tech] Re: DSpace7 imports via Simple Archive Format

[Matthias Letsch]

Hello Jan,

my guess is that you are missing the -z (--zip) argument for the actual zip 
file inside of your folder im --source. In this zip file you should contain 
the files, a content file containing the filenames of your files and a 
dublin_core.xml:

e.g.

example.zip
- file.pdf (the actual file)
- contents (only contains string "file.pdf" in this case)
- dublin_core.xml (contains metadata)

So your command should look like this:

"/opt/dspace-backend_7.6/bin/dspace import --add --eperson=mye...@uk.zcu.cz 
 --collection=123456789/55044 
--source=/opt/import/1603103069943/39795/79093* --zip=example.zip* 
--mapfile=/opt/import/index1.txt" 

Kind regards,
Matthias
Jan Broulím schrieb am Montag, 4. März 2024 um 11:24:05 UTC+1:

> Hello,
>
> I am currently testing imports with DSpace7 in a similar way which we were 
> using for DSpace5.
> The directory contains: contents, dublin_core.xml and files listed in 
> contents (the same was working in DSpace5).
>
> When running the command "/opt/dspace-backend_7.6/bin/dspace import --add 
> --eperson=mye...@uk.zcu.cz --collection=123456789/55044 
> --source=/opt/import/1603103069943/39795/79093 
> --mapfile=/opt/import/index1.txt"
>
> I obtain no error
>
> The script has started
> Destination collections:
> Owning Collection: Kolekce pro testy
> Started: 1709547590250
> Ended: 1709547592664
> Elapsed time: 2 secs (2414 msecs)
> The script has completed
>
> BUT ALSO NO FILES ARE IMPORTED.
> If I change the --source parameter and replace it with a wrong directory, 
> the script terminates with an error - which is OK.
>
> May I please ask for any help?
>
> Thank you
>
> Jan
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/759bf58d-0d47-4d7f-904b-231575de615fn%40googlegroups.com.

[dspace-tech] Re: Set all DSpace items that do not have an associated file (bitstream) as private

[Matthias Letsch]

Hello Javi,

Do you mean to make them only accessible to administrator? And do you 
already have a list of the uuids of your items you want to make private? 
(the long hash value which also appears in the url of an item).

If so, and if you are somewhat familiar with SQL and the DSpace database, 
I'd suggest you could make the changes directly via sql update in the 
resourcepolicy table in your database.

*Disclaimer: Please take this approach with a grain of salt and test it on 
a single item first, preferably in your test environment / test database. I 
don't know if there is a solution via the user interface, so this is what I 
would do, but if someone knows a more simple and secure solution via the 
user interface, I would also prefer the latter!*

update resourcepolicy
set rpname = 'administrator', rptype = 'TYPE_CUSTOM', epersongroup_id = '*uuid 
of your administrator group*' 
where resource_type_id = 2 and action_id = 0 and dspace_object in (*comma 
separated list of your uuids*)

this changes the existing access policies of your items to your 
administrator group only (you have to know the uuid of your administrator 
group, too).

If you are not yet able to identify your items exactly by uuid, it will be 
a little more difficult, as you will then have to work across several 
tables (item2bundle, bundle2bitstream) to find out which items do not have 
bistreams. I can't go into this in detail at this point.

Kind regards,
Matthias



Javi Rojo Díaz schrieb am Montag, 26. Februar 2024 um 10:27:50 UTC+1:

> Good morning, 
>
> I wanted to ask if there is any way to set all DSpace items that do not 
> have an associated file as private.
>  
> I know it's a bit of a stretch and I can't find information about it, but 
> I would appreciate any help. Otherwise, I understand that I will have to do 
> it manually, and there are about 700 items... 
>
> Thank you for your assistance. Best regards."
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/581fff35-38e5-4892-9f8c-979cf09cf89en%40googlegroups.com.

[dspace-tech] Re: How to set up Tombstones in DSpace 7.6?

[Matthias Letsch]

Hello Carolyn,

If you withdraw an item in the status tab instead of deleting it, the 
tombstone should be displayed automatically when you go to the item page 
when not logged in as an admin. The item won't be available via search 
after withdrawn, but if you enter the url of the item you will see a simple 
note that it has been withdrawn.

Kind regards,
Matthias

Carolyn Sullivan schrieb am Donnerstag, 22. Februar 2024 um 18:01:18 UTC+1:

> Hello,
>
> Right now when I delete an item, I see the message ' Are you sure this 
> item should be completely deleted? Caution: At present, no tombstone would 
> be left.' 
>
> How do I configure tombstones in 7.6?  I can't seem to find any labels 
> corresponding to tombstones.  In 6.3, there was a file tombstone.jsp, and 
> customisable text corresponding to it in Messages.properties, ie: 
> jsp.tombstone.title, jsp.tombstone.text
>
> Any assistance would be dearly appreciated, and thank you so much for your 
> time.
>
> Best,
> Carolyn Sullivan, B.Sc., M.L.I.S.
> Systems Librarian for Digital Repositories
> University of Ottawa
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/61ff843d-2db6-4b0d-badd-67bf98db0251n%40googlegroups.com.

[dspace-tech] Re: Add Field like the URL field in Items

[Matthias Letsch]

Hello Vahe,

Which DSpace version do you use? The answer depends on the version. I can 
only give advise for Version 7.x.

If you use Dspace 7.x, you have to make changes in the correspondend html 
template in your dspace-angular source code (in your used theme, e.g. 
src/themes/custom/app) and recompile your code afterwards. So you need to 
know some stuff about the angular frontend in order to do that.

(additionally, you may want to make this field available in your submission 
form, which would be another extra step).

In vanilla Dspace 7, the following template is generating your item page by 
default:
[path to your 
theme]/app/item-page/simple/item-types/untyped-item/untyped-item.component.html

Please note: If you have activated the publication entities (which is not 
activated by default), you need to edit .../ 
item-types/publication/publication.component.html instead.

The metadata displayed on the item page is divided into two columns by 
default. In the html template file, choose the column in which you want to 
have dc.identifier.doi displayed and add this at the desired position:




You should thy such changes in developer mode. But so much for now. If you 
use Dspace 7 and would like to know more about this, please just reply.

Kind regards
Matthias
Vahe Ghorghorian schrieb am Freitag, 23. Februar 2024 um 09:55:21 UTC+1:

> Hello Everyone i have the following item dc.identifier.doi . i would like 
> this field to appear when i add a new item under a collection how can i 
> make it appear ? 
> thank you 
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/e2a1c893-be41-4365-9dc1-1624a7661946n%40googlegroups.com.

[dspace-tech] Re: DSpace 7.6.1 How to suppress automatic DOI generation and registration for imported items?

[Matthias Letsch]

Hi Agustina,

thank you, that is exactly what I was looking for!

To be honest, I actually managed to somehow overlook the section "Configure 
filters and behavior" in the documentation 
(https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier)... 
So thank you for that.

I have adapted the filter so that it excludes all items that already 
contain a value dc.identifier.uri with the value "doi" or a doi pattern 
(regex 10\.\d{5}). In addition, the imports are excluded by a specific 
value in the dc.relations field, which only these imports contain. This 
covers my cases so far.

After archiving the items, the DOI has the status "(Minted (not 
registered))", so it is not passed on to DataCite. This may already be 
sufficient for my case, but it would be even more practical if it were 
completely discarded (status DELETED) so that all the numbers are not 
wasted. According to the documentation, it should be possible to configure 
a filter accordingly:

*Users often want to see what DOI they will  get so they can alter their 
PDF, coverpage, other metadata, and so on.*

*This feature should ensure that users can see their future DOI, and if 
necessary, a warning that if certain conditions are not met, the DOI will 
not be registered after approval.*
(https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier) 

However, it is not explained in detail how exactly this can be set up. Can 
you possibly help here, too?

Thank you again
Matthias

Agustina Martinez-Garcia schrieb am Mittwoch, 21. Februar 2024 um 16:11:48 
UTC+1:

> Hi Matthias,
>
> I believe what you are after is achieved via configuring DOI filters in 
> spring/api/item-filtering.xml. Have a look at the example filter named 
> "doi-filter".
>
> This is the approach we take to avoid DOIs being registered in specific 
> cases, e.g. the item we are importing already has an external DOI. Once the 
> filter that meets your criteria is added, you can then configure the doi 
> provider bean in identifiers.xml to use that filter. Via the DSpace 
> configuration you can also set whether you want the filter to apply at 
> submission stage (pre-registering DOIs) or only when installing items.
>
> I hope this helps.
>
> Agustina
>
> On Wednesday 21 February 2024 at 09:24:03 UTC Matthias Letsch wrote:
>
>> Hi there,
>>
>> I'd like to repeat my question, because I still really need support with 
>> this.
>>
>> Brief summary: 
>> - Items that are entered by users via the input mask should generally 
>> receive their own DOIs (with the exception of secondary publications that 
>> already have a different DOI). 
>> - Imports via SAF or from other external sources, however, shall not 
>> (expensive and/or redundand). A SAF mass import with over 8000 items is 
>> being planned.
>> - The DOI service in DSpace apparently works in such a way that either 
>> ALL items whit no exceptions get an in-house DOI (activated) or 
>> alternatively NO item at all (deactivated).
>>
>> --> I currently know that I can comment out the DOIIdentifierprovider.xml 
>> in identifier-service.xml and restart the server in order to completely 
>> interrupt the DOI generation for the period of my SAF import (which can 
>> take a very long time). However, this cannot be the desired approach, as it 
>> means that no other user should enter any other new item during this time, 
>> for which item an in-house DOI may be necessary after all.
>>
>> I have read through the documentation at 
>> https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier, 
>> but it does not cover the case of exceptions.
>>
>> Is there really no other possibility to make items exceptions to the 
>> automatic doi generation while activated? Maybe I'm missing something 
>> obvious, but as of now I haven't found a place where I could set anything 
>> regarding for which items DOIs should be provided and which not.
>>
>> It's hard for me to imagine that no other institution has similar 
>> requirements to those mentioned above. (As far as I can tell all repository 
>> providers with both open access second publications and in-house first 
>> publications need to ensure that a new DOI may only be generated in certain 
>> cases). I would really appreciate any advice or other experiences on this 
>> matter!
>>
>> Thank you and kind regards,
>> Matthias
>>
>> Matthias Letsch schrieb am Freitag, 2. Februar 2024 um 17:20:42 UTC+1:
>>
>>> Hi there,
>>>
>>> I have activated automatic DOI generation and registration for new items 
>>> on Datacite. Above all, items that are newly submitted manua

[dspace-tech] Various questions about the submission user interface

[Matthias Letsch]

Hi there,

I have a few questions about the submission form:

1. input type name: According to the documentation, there is still the 
imput type name, but it is no longer used by default:

*"name* – Personal name, with separate fields for family name and first 
name. When saved they are appended in the format 'LastName, FirstName'.  *(By 
default, this input type is unused. Author fields now use the "onebox" type 
to support different types of names.)*"

(https://wiki.lyrasis.org/display/DSDOC7x/Submission+User+Interface#SubmissionUserInterface-Reordering/Removing/AddingSubmissionSteps)

I would like to set this input type for our author information, however 
after the change in submission-form.xml the form still simply displays a 
onebox. Is this input type still current or do I have to set something else 
for it to work?

2. inserting links in notes: For certain fields it would be useful to 
provide users with links to external pages. Is there any way to insert a 
clickable link into the fields, either in  or in another tag?

3. pure information texts without dependence on a specific field: I would 
like to include an area for general information on the input mask. Can I 
implement this via submission-forms.xml or do I have to create a completely 
new submission step class for this?

Thnak you and kind regards,
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/a0fa49f3-2950-4967-8539-0dda6cd7a811n%40googlegroups.com.

[dspace-tech] Re: DSpace 7.6.1 How to suppress automatic DOI generation and registration for imported items?

[Matthias Letsch]

Hi there,

I'd like to repeat my question, because I still really need support with 
this.

Brief summary: 
- Items that are entered by users via the input mask should generally 
receive their own DOIs (with the exception of secondary publications that 
already have a different DOI). 
- Imports via SAF or from other external sources, however, shall not 
(expensive and/or redundand). A SAF mass import with over 8000 items is 
being planned.
- The DOI service in DSpace apparently works in such a way that either ALL 
items whit no exceptions get an in-house DOI (activated) or alternatively 
NO item at all (deactivated).

--> I currently know that I can comment out the DOIIdentifierprovider.xml 
in identifier-service.xml and restart the server in order to completely 
interrupt the DOI generation for the period of my SAF import (which can 
take a very long time). However, this cannot be the desired approach, as it 
means that no other user should enter any other new item during this time, 
for which item an in-house DOI may be necessary after all.

I have read through the documentation at 
https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier, but 
it does not cover the case of exceptions.

Is there really no other possibility to make items exceptions to the 
automatic doi generation while activated? Maybe I'm missing something 
obvious, but as of now I haven't found a place where I could set anything 
regarding for which items DOIs should be provided and which not.

It's hard for me to imagine that no other institution has similar 
requirements to those mentioned above. (As far as I can tell all repository 
providers with both open access second publications and in-house first 
publications need to ensure that a new DOI may only be generated in certain 
cases). I would really appreciate any advice or other experiences on this 
matter!

Thank you and kind regards,
Matthias

Matthias Letsch schrieb am Freitag, 2. Februar 2024 um 17:20:42 UTC+1:

> Hi there,
>
> I have activated automatic DOI generation and registration for new items 
> on Datacite. Above all, items that are newly submitted manually via the 
> submission form should receive a DOI.
>
> I am also currently testing a mass import of an old external repository 
> via batch import (SAF). This involves a quantity of around 8k items. 
>
> For a subset of about 150 items imported yesterday as a test, all items 
> have now been automatically provided with new DOIs and these have been sent 
> to Datacite fabrica test. However, these items (old journal articles) 
> should not receive a DOI at all, as some of them already have one. 
> Furthermore, registering all these items in the productive system would be 
> incredibly expensive. It is therefore absolutely necessary to suspend the 
> DOI registration for these items.
>
> I have also noticed that a new DOI is always generated automatically when 
> importing e.g. articles from external sources such as CrossRef, which a 
> user can also initiate. However, most imported articles already have a DOI.
>
> Is there a way to prevent DOI registration for imports without 
> deactivating it completely? Or can it be set somewhere so that only items 
> received via the input screen actually receive a new DOI?
>
> Thank you and kind regards,
> Matthias
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/79918478-2775-4715-905f-7877e97578d9n%40googlegroups.com.

[dspace-tech] DSpace 7.6.1 How to suppress automatic DOI generation and registration for imported items?

[Matthias Letsch]

Hi there,

I have activated automatic DOI generation and registration for new items on 
Datacite. Above all, items that are newly submitted manually via the 
submission form should receive a DOI.

I am also currently testing a mass import of an old external repository via 
batch import (SAF). This involves a quantity of around 8k items. 

For a subset of about 150 items imported yesterday as a test, all items 
have now been automatically provided with new DOIs and these have been sent 
to Datacite fabrica test. However, these items (old journal articles) 
should not receive a DOI at all, as some of them already have one. 
Furthermore, registering all these items in the productive system would be 
incredibly expensive. It is therefore absolutely necessary to suspend the 
DOI registration for these items.

I have also noticed that a new DOI is always generated automatically when 
importing e.g. articles from external sources such as CrossRef, which a 
user can also initiate. However, most imported articles already have a DOI.

Is there a way to prevent DOI registration for imports without deactivating 
it completely? Or can it be set somewhere so that only items received via 
the input screen actually receive a new DOI?

Thank you and kind regards,
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/d481a19c-bb32-4781-af0a-218e6015ba67n%40googlegroups.com.

[dspace-tech] Dspace 7.6.1 Batch import via SAF fails due to "invalid" imports directory

[Matthias Letsch]

Hi there,

I am trying to import prepared SAF files via batch import. With another 
subset in other collections, this worked wonderfully just yesterday. So it 
can't be the SAF files, they follow exactly the same pattern (zip with 
folders containing xyz.pdf, dublin_core.xml and contents referring to pdf 
file.

Today, however, I get an error message (This is now a dedicated test import 
into a newly created collection TEST):

###:~/dspace-backend/bin$ ./dspace import -a -e ###@###.de -s ~/ojs-import 
-z 10.zip -c 12345678
9/5103 -m ~/ojs-import/mapfiles/test10;
The script has started
Destination collections:
Owning Collection: TEST
'/home/dspace/dspace-backend/imports' as defined by the key 
'org.dspace.app.batchitemimport.work.dir' in dspace.cfg is not a valid 
directory
Started: 1706876840214
Ended: 1706876846622
Elapsed time: 6 secs (6408 msecs)
java.lang.Exception: Error committing changes to database: Error, cannot 
open source directory 
/home/dspace/dspace-backend/imports/importSAF/43013a47-6076-432a-959d-9805240a43ae/10.zip,
 
aborting most recent changes
at 
org.dspace.app.itemimport.ItemImport.internalRun(ItemImport.java:233)
at org.dspace.scripts.DSpaceRunnable.run(DSpaceRunnable.java:150)
at 
org.dspace.app.launcher.ScriptLauncher.executeScript(ScriptLauncher.java:154)
at 
org.dspace.app.launcher.ScriptLauncher.handleScript(ScriptLauncher.java:132)
at 
org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:99)
Caused by: java.lang.Exception: Error, cannot open source directory 
/home/dspace/dspace-backend/imports/importSAF/43013a47-6076-432a-959d-9805240a43ae/10.zip
at 
org.dspace.app.itemimport.ItemImportServiceImpl.addItems(ItemImportServiceImpl.java:278)
at 
org.dspace.app.itemimport.ItemImportCLI.process(ItemImportCLI.java:92)
at 
org.dspace.app.itemimport.ItemImport.internalRun(ItemImport.java:226)
... 4 more

As I understand it, there is some problem with the folder 
(dspace-dir)/imports, which exists exactly as it is defined in dspace.cfg.

If I create a new, different folder in the backend and then change this in 
dspace.cfg (plus restart tomcat), the result unfortunately looks exactly 
the same.

Does anyone know how to fix this problem?

Thank you and kind regards
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/07b05c25-f1ce-4dd1-901b-74ff7e9f983bn%40googlegroups.com.

[dspace-tech] Re: DSpace 7.6.1 - Remove "Have you Forgot your password?" or link somewhere else

[Matthias Letsch]

Hi Tomas,

at least I can give you the location where this can be changed in the 
source code of the angular-frontend.

There is a component 
.../src/app/shared/log-in/methods/password/log-in-password.component.html 
that should look like this:


  {{"login.form.email" | translate}}
  
  {{"login.form.password" | translate}}
  
  {{ (error | async) |
translate }}
  {{ (message | async) |
translate }}

   
{{"login.form.submit" | translate}}



  
{{ 'login.form.new-user' | translate }}
  
  
{{ 'login.form.forgot-password' | translate }}
  


I assume that the ldap authentication method also uses this component, 
since there is no other component that uses the forgot password link.

Commenting out or deleting the last link in the html file ensures that the 
link is no longer displayed.


{{ 'login.form.forgot-password' | translate }}
  

(You may want to copy the component into your own theme, but I have not 
tested whether further changes are then necessary.)

Kind regards,
Matthias
Tomas Hajek schrieb am Dienstag, 23. Januar 2024 um 15:38:17 UTC+1:

> Hi,
>   I'm currently running DSpace version 7.6.1 and using LDAP 
> authentication.  I'm wondering if there is a method of either removing 
> the "Have you Forgot your password?" link or being able to change the link 
> to point to another site. 
>   I saw a related issue (https://github.com/DSpace/DSpace/issues/8293) 
> but it looks like that is still on the "To Do" board for 7.6.x (
> https://github.com/orgs/DSpace/projects/29/views/1?filterQuery=8293).
>   I've attempted using an Apache HTTPD rewrite rule to redirect /forgot to 
> the password reset page that we want users to use but that only seems to 
> work if the user goes directly to the /forgot URL.  I'm guessing that when 
> a user clicks on the link under the "Login" drop-down that it is JavaScript 
> doing the URL change so it doesn't actually hit the Apache HTTPD server in 
> order to do a rewrite (although I could be doing it wrong).
>   My next attempt might be to change the forgot-password-form Angular 
> components in the theme but that might cause me other issues.
>   Does anyone have any suggestions?
> Thanks for your help!
>  -Tomas
>
>
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/74930511-23d6-4aae-a80b-c2dc1dad83a0n%40googlegroups.com.

[dspace-tech] No automatic login after setting/changing password

[Matthias Letsch]

Hello,

we have two types of users:
1. University members which login via Shibboleth with their university 
account
2. In exceptional cases: External users who are created via the admin with 
a valid email address.

We have deactivated independent registration by the users themselves, 
because we only want such accounts in exceptional cases and also those 
"registered" accounts are created directly in DSpace before we admins even 
have a chance to check them.

So for External users we create accounts in the admin via Access control. 
But now the users have no password. So we have to click the Reset password 
button to trigger an e-mail with the password link for the user.

If the user successfully changes his password, he is logged in directly, 
but unfortunately does NOT see the end user agreement, which normally 
everyone (whether via Shibboleth or externally) has to accept (We have 
included important information about data usage in the account etc. in 
it.). This is because the end user agreement by default is only activated 
when you log in "normally" via the login on the start page.

However, it is important to us that every user sees and accepts the end 
user agreement when they log in for the first time.

Therefore, I see two options here: 1. either we get it so that the end user 
agreement is displayed also directly after the password change (which is in 
this case the first login) OR 2. the user is NOT logged in directly after 
changing the password.

How can I set up the corresponding components so that they do either one or 
the other?

(OR Option 3, where it all comes from: The registration by the user himself 
can be set up in a way that there is NO account created directly before any 
of us admins can click on "approve" oder "deny". But how do I do that?)


-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/6e87ee97-9015-4329-b8e6-0f3e429133f0n%40googlegroups.com.

Re: [dspace-tech] Continue to display item metadata publicly after withdrawal

[Matthias Letsch]

Hi Deborah,

thanks for your reply and yes, that's actually the alternative solution I 
was thinking about, making the bitstream accessible only to admins and 
adding a note in dc.description. The only disadvantage would then be that 
the item is not marked as withdrawn in the database, which means that it 
would not be possible to make statistical evaluations from this field, for 
example. Just in case we ever need it. But even then you can query 
dc.description if necessary, it just might not be quite as clean.

Kind regards,
Matthias

Fitchett, Deborah schrieb am Donnerstag, 30. November 2023 um 21:39:44 
UTC+1:

> Would it work for you to simply delete the bitstream(s) or bundle(s), or 
> to make them admin-only, and edit the metadata?
>
>  
>
> The metadata is part of the item, so withdrawing the item is expected to 
> withdraw the metadata too.
>
>  
>
> (This said, in DSpace 5.x we got someone to fiddle with the tombstone page 
> to display a replacedBy link if that was in the metadata. But I haven’t 
> investigated the feasibility of that in DSpace 7.)
>
>  
>
> Deborah
>
>  
>
> *From:* dspac...@googlegroups.com  *On Behalf 
> Of *Matthias Letsch
> *Sent:* Friday, December 1, 2023 3:22 AM
> *To:* DSpace Technical Support 
> *Subject:* [dspace-tech] Continue to display item metadata publicly after 
> withdrawal
>
>  
>
> *Caution:* This email originated from outside our organisation. Do not 
> click links or open attachments unless you recognize the sender and know 
> the content is safe.
>
>  
>
> Hello,
>
>  
>
> If an item is withdrawn, the tombstone page will only display a simple 
> note that the item has been withdrawn. The rest of the original landing 
> page is then only visible as an admin.
>
> I would like to display the item page in such a way that the metadata of 
> the item still remains publicly visible, e.g. to give the reason for the 
> withdrawal and an indication of a new/corrected/alternative publication in 
> dc.description. Of course, the file should then no longer be available. (I 
> do not want to enable versioning for our items for various reasons.)
>
> Can I set this up somehow? E.g. via the access control - or do I really 
> have to rework the corresponding components in the frontend?
>
> -- 
> 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 dspace-tech...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dspace-tech/a71d071e-b6cc-4752-bbdc-4f4b5400fa47n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/dspace-tech/a71d071e-b6cc-4752-bbdc-4f4b5400fa47n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> --
>
> "The contents of this e-mail (including any attachments) may be 
> confidential and/or subject to copyright. Any unauthorised use, 
> distribution, or copying of the contents is expressly prohibited. If you 
> have received this e-mail in error, please advise the sender by return 
> e-mail or telephone and then delete this e-mail together with all 
> attachments from your system." 
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/5a706773-a97e-4808-a7b0-6a1fba267c04n%40googlegroups.com.

[dspace-tech] Continue to display item metadata publicly after withdrawal

[Matthias Letsch]

Hello,

If an item is withdrawn, the tombstone page will only display a simple note 
that the item has been withdrawn. The rest of the original landing page is 
then only visible as an admin.

I would like to display the item page in such a way that the metadata of 
the item still remains publicly visible, e.g. to give the reason for the 
withdrawal and an indication of a new/corrected/alternative publication in 
dc.description. Of course, the file should then no longer be available. (I 
do not want to enable versioning for our items for various reasons.)

Can I set this up somehow? E.g. via the access control - or do I really 
have to rework the corresponding components in the frontend?

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/a71d071e-b6cc-4752-bbdc-4f4b5400fa47n%40googlegroups.com.

Re: [dspace-tech] Dspace 7.6.1 Doi registration error (DataCite)

[Matthias Letsch]

Okay, I have found the causes of both problems:

Problem 1: Status doesn't switch to "queued for registration" when accepted
Cause: In the context of Configuring pre-registration of Identifiers I 
accidentally set "identifiers.submission.filter.install = doi-filter" in 
config/modules/identifiers.cfg.
Solution: Set identifiers.submission.filter.install = always_true_filter 
(default)

Problem 2: error "Database table DOI contains a DOI  that is not valid" in 
command ./dspace doi-organiser -r
Cause: The error message also states the following below: "Caused by: 
java.lang.IllegalArgumentException: Handle is null" so no handle is 
generated for the new item. DataCite needs to link the registered doi to an 
item url which appears to be the metadata value 
"{dspace.ui.url}/handle/123456789/x" (e.g. .../handle/123456789/7) in 
dc.identifier.uri. Since no handle is created, no uri can be delivered to 
datacite and the doi status of the item does not switch.
Solution: In config/spring/api/identifier-service the bean for the 
HandleIdentifierProvider has to be uncommented:





Caution: If versioning is disabled, the class must be corrected to 
org.dspace.identifier.HandleIdentifierProvider

The HandleIdentifierProvider creates a handle for the new item.

The handle doesn't need to be registered anywhere, it just has to be there 
in dc.identifier.uri

Kind regards,
Matthias
Matthias Letsch schrieb am Montag, 6. November 2023 um 15:42:54 UTC+1:

> Thank you Manuele!
>
> Unfortunately, the typo only happened to me here in the problem 
> description.
>
> The correct test prefix at DataCite is 10.82770 and also in the dspace.cfg 
> is identifier.doi.prefix = 10.82770
>
> So the numbers match. The problem must lie elsewhere.
>
> Kind regards,
> Matthias
>
> Manuele Lorusso schrieb am Montag, 6. November 2023 um 15:09:36 UTC+1:
>
>> Hello Matthias,
>>
>> probably your config "identifier.doi.prefix" was overwritten through the 
>> upgrade or a typo has happened
>>
>> Your registered DataCite DOI Prefix (10.87220) differs from the prefix in 
>> the Exception Message (10.82770).
>>
>> Best,
>> Manuele
>>
>> Herr Manuele Lorusso
>> Softwareentwickler / Abt. IT-Dienste Forschung, Lehre, Infrastruktur
>> Kommunikations-, Informations-, Medienzentrum (KIM)
>> Universität Konstanz
>> 78457 Konstanz+49 (0)7531 / 88-5403 <+49%207531%20885403>
>> Raum B 707
>>
>> On 03.11.23 13:53, Matthias Letsch wrote:
>>
>> Hello together,
>>
>>  
>>
>> we have a DataCite membership and doi registration to our fabrica test 
>> environment just worked fine with the configurations set like described in 
>> https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier. 
>> We use the DataCite API directly.
>>
>>  
>>
>> some weeks ago we updated up to version 7.6.1-SNAPSHOT (because of the 
>> "browse by subject group" bugfix). I also updated all necessary 
>> configuration files regarding the doi registration process:
>> - config/dspace.cfg (everything in "DOI registration agency credential" 
>> as well as "crosswalk.dissemination.DataCite.publisher")
>>
>> - config/spring/api/identifier-service.xml (see attachment)
>>
>> - config/item-submission.xml (only for showing pending dois in the 
>> submission form)
>>
>> - config/modules/identifiers.cfg (see attachment)
>>
>>  
>>
>> By submission a doi is created in the following syntax: 10.87220/x (x = 
>> serial number, e.g. 10.87220/7 etc.)
>>
>> Now our doi registration has some strange behaviors and I don’t 
>> understand where they come from:
>>
>> 1. The status of the doi doesn't switch automatically from "pending" 
>> to "Queued for registration" when a new submission is accepted by admin. 
>> (Before the update to 7.6.1, this was the case). 
>>
>> 2. So I enabled „registering doi from admin“ to manually set the 
>> status "Queued for registration" in the status tab of the item via 
>> "identifiers.item-status.register-doi = true" in 
>> config/modules/identifiers.cfg.
>>
>> 3. Now, with some items with doi status "queued for registration" 
>> (database: 1), I used the typical dspace commands „./dspace doi-organiser 
>> -u/-s/-r/-d“, but in command –r (register) an error occured:
>>
>>  
>>
>> It wasn't possible to register this identifier: doi:10.82770/7
>> Exception: Database table DOI contains a DOI  that is not valid: 
>> doi:10.82770/7!
>> java.la

Re: [dspace-tech] Dspace 7.6.1 Doi registration error (DataCite)

[Matthias Letsch]

Thank you Manuele!

Unfortunately, the typo only happened to me here in the problem description.

The correct test prefix at DataCite is 10.82770 and also in the dspace.cfg 
is identifier.doi.prefix = 10.82770

So the numbers match. The problem must lie elsewhere.

Kind regards,
Matthias

Manuele Lorusso schrieb am Montag, 6. November 2023 um 15:09:36 UTC+1:

> Hello Matthias,
>
> probably your config "identifier.doi.prefix" was overwritten through the 
> upgrade or a typo has happened
>
> Your registered DataCite DOI Prefix (10.87220) differs from the prefix in 
> the Exception Message (10.82770).
>
> Best,
> Manuele
>
> Herr Manuele Lorusso
> Softwareentwickler / Abt. IT-Dienste Forschung, Lehre, Infrastruktur
> Kommunikations-, Informations-, Medienzentrum (KIM)
> Universität Konstanz
> 78457 Konstanz+49 (0)7531 / 88-5403 <+49%207531%20885403>
> Raum B 707
>
> On 03.11.23 13:53, Matthias Letsch wrote:
>
> Hello together,
>
>  
>
> we have a DataCite membership and doi registration to our fabrica test 
> environment just worked fine with the configurations set like described in 
> https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier. 
> We use the DataCite API directly.
>
>  
>
> some weeks ago we updated up to version 7.6.1-SNAPSHOT (because of the 
> "browse by subject group" bugfix). I also updated all necessary 
> configuration files regarding the doi registration process:
> - config/dspace.cfg (everything in "DOI registration agency credential" as 
> well as "crosswalk.dissemination.DataCite.publisher")
>
> - config/spring/api/identifier-service.xml (see attachment)
>
> - config/item-submission.xml (only for showing pending dois in the 
> submission form)
>
> - config/modules/identifiers.cfg (see attachment)
>
>  
>
> By submission a doi is created in the following syntax: 10.87220/x (x = 
> serial number, e.g. 10.87220/7 etc.)
>
> Now our doi registration has some strange behaviors and I don’t understand 
> where they come from:
>
> 1. The status of the doi doesn't switch automatically from "pending" 
> to "Queued for registration" when a new submission is accepted by admin. 
> (Before the update to 7.6.1, this was the case). 
>
> 2. So I enabled „registering doi from admin“ to manually set the 
> status "Queued for registration" in the status tab of the item via 
> "identifiers.item-status.register-doi = true" in 
> config/modules/identifiers.cfg.
>
> 3. Now, with some items with doi status "queued for registration" 
> (database: 1), I used the typical dspace commands „./dspace doi-organiser 
> -u/-s/-r/-d“, but in command –r (register) an error occured:
>
>  
>
> It wasn't possible to register this identifier: doi:10.82770/7
> Exception: Database table DOI contains a DOI  that is not valid: 
> doi:10.82770/7!
> java.lang.IllegalStateException: Database table DOI contains a DOI  that 
> is not valid: doi:10.82770/7!
> at (...)
>
>  
>
> How is 10.82770/7 not valid? DSpace did register all dois with that syntax 
> just fine before the dspace version update. 
>
>  
>
> 4. So I concluded that the registration didn’t work. Yet here the 
> funny thing is: I looked up our datacite fabrica test environment at 
> https://doi.test.datacite.org/ and there a new item with doi 10.82770/7 
> actually found its way to the registered dois. So DSpace did send the doi 
> to DataCite. BUT in our dspace database at table doi, the doi 10.82770/7 
> STILL has status 1 instead of 3 (1 = queued for registration, 3 = 
> registered) and no doi was written into the metadata (dc.identifier).
>
>  
>
> Does anyone know how this can happen and which configuration file I need 
> to change?
>
> Thank you very much!
>
> Kind regards,
>
> Matthias
>
> -- 
> 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 dspace-tech...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dspace-tech/9bc03cb4-0167-4891-9283-8d1f0a23585cn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/dspace-tech/9bc03cb4-0167-4891-9283-8d1f0a23585cn%40googlegroups.com?utm_medium=email_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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/43f5c2c5-0062-444d-ba66-ae4ab190d127n%40googlegroups.com.

[dspace-tech] Dspace 7.6.1 Doi registration error (DataCite)

[Matthias Letsch]

 

Hello together,

 

we have a DataCite membership and doi registration to our fabrica test 
environment just worked fine with the configurations set like described in 
https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier. We 
use the DataCite API directly.

 

some weeks ago we updated up to version 7.6.1-SNAPSHOT (because of the 
"browse by subject group" bugfix). I also updated all necessary 
configuration files regarding the doi registration process:
- config/dspace.cfg (everything in "DOI registration agency credential" as 
well as "crosswalk.dissemination.DataCite.publisher")

- config/spring/api/identifier-service.xml (see attachment)

- config/item-submission.xml (only for showing pending dois in the 
submission form)

- config/modules/identifiers.cfg (see attachment)

 

By submission a doi is created in the following syntax: 10.87220/x (x = 
serial number, e.g. 10.87220/7 etc.)

Now our doi registration has some strange behaviors and I don’t understand 
where they come from:

1. The status of the doi doesn't switch automatically from "pending" to 
"Queued for registration" when a new submission is accepted by admin. 
(Before the update to 7.6.1, this was the case). 

2. So I enabled „registering doi from admin“ to manually set the status 
"Queued for registration" in the status tab of the item via 
"identifiers.item-status.register-doi = true" in 
config/modules/identifiers.cfg.

3. Now, with some items with doi status "queued for registration" 
(database: 1), I used the typical dspace commands „./dspace doi-organiser 
-u/-s/-r/-d“, but in command –r (register) an error occured:

 

It wasn't possible to register this identifier: doi:10.82770/7
Exception: Database table DOI contains a DOI  that is not valid: 
doi:10.82770/7!
java.lang.IllegalStateException: Database table DOI contains a DOI  that is 
not valid: doi:10.82770/7!
at (...)

 

How is 10.82770/7 not valid? DSpace did register all dois with that syntax 
just fine before the dspace version update. 

 

4. So I concluded that the registration didn’t work. Yet here the funny 
thing is: I looked up our datacite fabrica test environment at 
https://doi.test.datacite.org/ and there a new item with doi 10.82770/7 
actually found its way to the registered dois. So DSpace did send the doi 
to DataCite. BUT in our dspace database at table doi, the doi 10.82770/7 
STILL has status 1 instead of 3 (1 = queued for registration, 3 = 
registered) and no doi was written into the metadata (dc.identifier).

 

Does anyone know how this can happen and which configuration file I need to 
change?

Thank you very much!

Kind regards,

Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/9bc03cb4-0167-4891-9283-8d1f0a23585cn%40googlegroups.com.

http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-2.5.xsd;>




  




































#--#
#-IDENTIFIER CONFIGURATIONS#
#--#
# These configs are used for additional identifier configuration such  #
# as the Show Identifiers step which can "pre-mint" DOIs and Handles   #
#--#

# Should configured  identifiers (eg handle and DOI) be minted for (future) 
registration at workspace item creation?
# A handle created at this stage will act just like a regular handle created at 
archive time.
# A DOI created at this stage will be in a 'PENDING' status while in workspace 
and workflow.
# At the time of item install, the DOI filter (if any) will be applied and if 
the item matches the filter, the DOI
# status will be updated to TO_BE_REGISTERED. An administrator can also 
manually progress the DOI status, overriding
# any filters, in the item status page.
# This option doesn't require the Show Identifiers submission step to be 
visible.
# Default: false
identifiers.submission.register = true

# This configuration property can be set to a filter name to determine if a 
PENDING DOI for an item
# should be queued for registration. If the filter doesn't match, the DOI will 
stay 

Re: [dspace-tech] Re: Shibboleth on DSpace 7.2 won't work for unknown reasons

[Matthias Letsch]

Hello Mark, thank You, I know, I just twisted it here. Still, now it works
without it but it won't if I have it inserted.

Thank you again for your help and have a great weekend!
Matthias

Am Fr., 30. Juni 2023 um 18:39 Uhr schrieb Mark H. Wood <
mwoodiu...@gmail.com>:

> On Fri, Jun 30, 2023 at 01:11:28AM -0700, Matthias Letsch wrote:
> > Thank you for your reply.
> >
> > I have the OIDs delivered by the IDP which are the following:
> >
> > urn:oid:1.3.6.1.4.1.5923.1.1.1.6
> > urn:oid:2.5.4.42
> > urn:oid:2.5.4.4
> > urn:oid:0.9.2342.19200300.100.1.3
> > urn:oid:2.16.840.1.113730.3.1.241
> >
> > So this is what I put into attribute-map.xml:
> >
> > 
> > 
> > 
> > 
> > 
> >
> > And this is on the other side in
> > [dspace-backend]/config/modules/authentication-shibboleth.cfg:
> >
> > authentication-shibboleth.netid-header = SHIB-NETID
> > authentication-shibboleth.email-header = SHIB-MAIL
> > (...)
> > authentication-shibboleth.firstname-header = SHIB-GIVENNAME
> > authentication-shibboleth.lastname-header = SHIB-SURNAME
> >
> > If I have the attributePrefix="_AJP" in shibboleth2.xml, nothing at all
> > arrives at DSpace from the login attempt. (403)
>
> That should be "AJP_" not "_AJP".  See
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html#env
>
> > If I delete it, at least there is a 401 "authentication failed" and
> > dspace.log throws the error mentioned above.
> >
> > I added 'allowedRequestAttributesPattern='SHIB-.*' to the AJP connector
> in
> > tomcat9/conf/server.xml
> >
> > The inherited result is still the same. To make matters worse, now this
> > morning after these minimal changes in the Shib XML files and in
> > server.xml, for some reason the following came up when I tried to reload
> > the page:
> >
> > Service Unavailable
> >
> > The server is temporarily unable to service your request due to
> maintenance
> > downtime or capacity problems. Please try again later.
> >
> > Apache/2.4.38 (Debian) Server at ... Port 443
> >
> > After resetting to the state before these changes the service runs
> normally
> > again (still without Shibboleth of course).Is it possible that it is
> > somehow due to the module? I don't know exactly, because our DSpace was
> > originally installed by an external company, but I guess that at the
> moment
> > only mod_proxy is used for the communication between Apache and Tomcat.
> >
> > Kind regards,
> > Matthias
> > Mark H. Wood schrieb am Donnerstag, 29. Juni 2023 um 15:57:26 UTC+2:
> >
> > > On Thu, Jun 29, 2023 at 03:10:32AM -0700, Matthias Letsch wrote:
> > > > This has at least resulted in the 403 becoming a 401 and DSpace
> noticing
> > > > something about the login attempt, which I consider positive
> progress.
> > > >
> > > > However, DSpace now complains in the logs that it cannot find the
> > > required
> > > > attributes:
> > > >
> > > > 2023-06-29 11:58:35,693 ERROR unknown unknown
> > > > org.dspace.authenticate.ShibAuthentication @ Shibboleth
> authentication
> > > was
> > > > not able to find a NetId, Email, or Tomcat Remote user for which to
> > > > indentify a user from.
> > > > 2023-06-29 11:58:35,707 ERROR unknown unknown
> > > > org.dspace.authenticate.ShibAuthentication @ Unable to register new
> > > eperson
> > > > because we are unable to find an email address along with first and
> last
> > > > name for the user.
> > > > NetId Header: 'SHIB-NETID'='null' (Optional)
> > > > Email Header: 'SHIB-MAIL'='null'
> > > > First Name Header: 'SHIB-GIVENNAME'='null'
> > > > Last Name Header: 'SHIB-SURNAME'='null'
> > > > 2023-06-29 11:58:35,709 INFO unknown unknown
> > > > org.dspace.app.rest.security.EPersonRestAuthenticationProvider @
> > > > anonymous::failed_login:email=null, result=4
> > > > 2023-06-29 11:58:35,719 ERROR unknown unknown
> > > > org.dspace.app.rest.security.StatelessLoginFilter @ Authentication
> > > failed
> > > > (status:401)
> > > > org.springframework.security.authentication.BadCredentialsException:
> > > Login
> > > > failed
> > > >
> > > > So I guess I need to modify the attribute-map.xml accordingly to
> match
> > > the
> > > > expected attributes under
> > > > [dspace]/c

Re: [dspace-tech] Re: Shibboleth on DSpace 7.2 won't work for unknown reasons

[Matthias Letsch]

Hi together, 

I solved it. I still had to adjust the 
apache2/sites-enabled/default-ssl.conf exactly according to the template on 
the documentation: 
https://wiki.lyrasis.org/display/DSDOC7x/Authentication+Plugins#AuthenticationPlugins-ShibbolethAuthentication

Now it works.

Matthias Letsch schrieb am Freitag, 30. Juni 2023 um 10:11:28 UTC+2:

> Thank you for your reply.
>
> I have the OIDs delivered by the IDP which are the following:
>
> urn:oid:1.3.6.1.4.1.5923.1.1.1.6 
> urn:oid:2.5.4.42 
> urn:oid:2.5.4.4 
> urn:oid:0.9.2342.19200300.100.1.3 
> urn:oid:2.16.840.1.113730.3.1.241 
>
> So this is what I put into attribute-map.xml: 
>
> 
> 
> 
> 
> 
>
> And this is on the other side in 
> [dspace-backend]/config/modules/authentication-shibboleth.cfg:
>
> authentication-shibboleth.netid-header = SHIB-NETID
> authentication-shibboleth.email-header = SHIB-MAIL
> (...)
> authentication-shibboleth.firstname-header = SHIB-GIVENNAME
> authentication-shibboleth.lastname-header = SHIB-SURNAME
>
> If I have the attributePrefix="_AJP" in shibboleth2.xml, nothing at all 
> arrives at DSpace from the login attempt. (403)
> If I delete it, at least there is a 401 "authentication failed" and 
> dspace.log throws the error mentioned above.
>
> I added 'allowedRequestAttributesPattern='SHIB-.*' to the AJP connector in 
> tomcat9/conf/server.xml
>
> The inherited result is still the same. To make matters worse, now this 
> morning after these minimal changes in the Shib XML files and in 
> server.xml, for some reason the following came up when I tried to reload 
> the page: 
>
> Service Unavailable
>
> The server is temporarily unable to service your request due to 
> maintenance downtime or capacity problems. Please try again later.
>
> Apache/2.4.38 (Debian) Server at ... Port 443
>
> After resetting to the state before these changes the service runs 
> normally again (still without Shibboleth of course).Is it possible that it 
> is somehow due to the module? I don't know exactly, because our DSpace was 
> originally installed by an external company, but I guess that at the moment 
> only mod_proxy is used for the communication between Apache and Tomcat.
>
> Kind regards,
> Matthias
> Mark H. Wood schrieb am Donnerstag, 29. Juni 2023 um 15:57:26 UTC+2:
>
>> On Thu, Jun 29, 2023 at 03:10:32AM -0700, Matthias Letsch wrote: 
>> > This has at least resulted in the 403 becoming a 401 and DSpace 
>> noticing 
>> > something about the login attempt, which I consider positive progress. 
>> > 
>> > However, DSpace now complains in the logs that it cannot find the 
>> required 
>> > attributes: 
>> > 
>> > 2023-06-29 11:58:35,693 ERROR unknown unknown 
>> > org.dspace.authenticate.ShibAuthentication @ Shibboleth authentication 
>> was 
>> > not able to find a NetId, Email, or Tomcat Remote user for which to 
>> > indentify a user from. 
>> > 2023-06-29 11:58:35,707 ERROR unknown unknown 
>> > org.dspace.authenticate.ShibAuthentication @ Unable to register new 
>> eperson 
>> > because we are unable to find an email address along with first and 
>> last 
>> > name for the user. 
>> > NetId Header: 'SHIB-NETID'='null' (Optional) 
>> > Email Header: 'SHIB-MAIL'='null' 
>> > First Name Header: 'SHIB-GIVENNAME'='null' 
>> > Last Name Header: 'SHIB-SURNAME'='null' 
>> > 2023-06-29 11:58:35,709 INFO unknown unknown 
>> > org.dspace.app.rest.security.EPersonRestAuthenticationProvider @ 
>> > anonymous::failed_login:email=null, result=4 
>> > 2023-06-29 11:58:35,719 ERROR unknown unknown 
>> > org.dspace.app.rest.security.StatelessLoginFilter @ Authentication 
>> failed 
>> > (status:401) 
>> > org.springframework.security.authentication.BadCredentialsException: 
>> Login 
>> > failed 
>> > 
>> > So I guess I need to modify the attribute-map.xml accordingly to match 
>> the 
>> > expected attributes under 
>> > [dspace]/config/modules/authentication-shibboleth.cfg. 
>> > 
>> > The documentation at 
>> > 
>> https://wiki.lyrasis.org/display/DSDOC7x/Authentication+Plugins#AuthenticationPlugins-ShibbolethAuthentication
>>  
>> > provides a template for attribute-map with the attributes that seem to 
>> > match at first glance. 
>> > 
>> > But unfortunately that alone does not change anything for us. Do you 
>> > possibly know more about this? 
>>
>> You need to know the OIDs used by your Shibboleth IDP to label the 
>> a

Re: [dspace-tech] Re: Shibboleth on DSpace 7.2 won't work for unknown reasons

[Matthias Letsch]

Thank you for your reply.

I have the OIDs delivered by the IDP which are the following:

urn:oid:1.3.6.1.4.1.5923.1.1.1.6 
urn:oid:2.5.4.42 
urn:oid:2.5.4.4 
urn:oid:0.9.2342.19200300.100.1.3 
urn:oid:2.16.840.1.113730.3.1.241 

So this is what I put into attribute-map.xml: 







And this is on the other side in 
[dspace-backend]/config/modules/authentication-shibboleth.cfg:

authentication-shibboleth.netid-header = SHIB-NETID
authentication-shibboleth.email-header = SHIB-MAIL
(...)
authentication-shibboleth.firstname-header = SHIB-GIVENNAME
authentication-shibboleth.lastname-header = SHIB-SURNAME

If I have the attributePrefix="_AJP" in shibboleth2.xml, nothing at all 
arrives at DSpace from the login attempt. (403)
If I delete it, at least there is a 401 "authentication failed" and 
dspace.log throws the error mentioned above.

I added 'allowedRequestAttributesPattern='SHIB-.*' to the AJP connector in 
tomcat9/conf/server.xml

The inherited result is still the same. To make matters worse, now this 
morning after these minimal changes in the Shib XML files and in 
server.xml, for some reason the following came up when I tried to reload 
the page: 

Service Unavailable

The server is temporarily unable to service your request due to maintenance 
downtime or capacity problems. Please try again later.

Apache/2.4.38 (Debian) Server at ... Port 443

After resetting to the state before these changes the service runs normally 
again (still without Shibboleth of course).Is it possible that it is 
somehow due to the module? I don't know exactly, because our DSpace was 
originally installed by an external company, but I guess that at the moment 
only mod_proxy is used for the communication between Apache and Tomcat.

Kind regards,
Matthias
Mark H. Wood schrieb am Donnerstag, 29. Juni 2023 um 15:57:26 UTC+2:

> On Thu, Jun 29, 2023 at 03:10:32AM -0700, Matthias Letsch wrote:
> > This has at least resulted in the 403 becoming a 401 and DSpace noticing 
> > something about the login attempt, which I consider positive progress.
> > 
> > However, DSpace now complains in the logs that it cannot find the 
> required 
> > attributes:
> > 
> > 2023-06-29 11:58:35,693 ERROR unknown unknown 
> > org.dspace.authenticate.ShibAuthentication @ Shibboleth authentication 
> was 
> > not able to find a NetId, Email, or Tomcat Remote user for which to 
> > indentify a user from.
> > 2023-06-29 11:58:35,707 ERROR unknown unknown 
> > org.dspace.authenticate.ShibAuthentication @ Unable to register new 
> eperson 
> > because we are unable to find an email address along with first and last 
> > name for the user.
> > NetId Header: 'SHIB-NETID'='null' (Optional)
> > Email Header: 'SHIB-MAIL'='null'
> > First Name Header: 'SHIB-GIVENNAME'='null'
> > Last Name Header: 'SHIB-SURNAME'='null'
> > 2023-06-29 11:58:35,709 INFO unknown unknown 
> > org.dspace.app.rest.security.EPersonRestAuthenticationProvider @ 
> > anonymous::failed_login:email=null, result=4
> > 2023-06-29 11:58:35,719 ERROR unknown unknown 
> > org.dspace.app.rest.security.StatelessLoginFilter @ Authentication 
> failed 
> > (status:401)
> > org.springframework.security.authentication.BadCredentialsException: 
> Login 
> > failed
> > 
> > So I guess I need to modify the attribute-map.xml accordingly to match 
> the 
> > expected attributes under 
> > [dspace]/config/modules/authentication-shibboleth.cfg. 
> > 
> > The documentation at 
> > 
> https://wiki.lyrasis.org/display/DSDOC7x/Authentication+Plugins#AuthenticationPlugins-ShibbolethAuthentication
>  
> > provides a template for attribute-map with the attributes that seem to 
> > match at first glance. 
> > 
> > But unfortunately that alone does not change anything for us. Do you 
> > possibly know more about this?
>
> You need to know the OIDs used by your Shibboleth IDP to label the
> attributes that you want. These may vary from site to site.
> attribute-map.xml maps them to names SHIB-NETID and the rest. If you
> don't give the right OIDs, nothing will be mapped into the request.
>
> You also need to know (or set) the request attributes that DSpace
> expects. That's the other side of the mapping.
>
> Here we are using attributePrefix='AJP_' and it works. We do not set
> ShibUseHeaders. Tomcat will strip the prefix and pass the attributes
> through in the Request. But Tomcat must be configured to accept more
> than the default set of attributes: the AJP connector must have
> 'allowedRequestAttributesPattern='SHIB-.*' to let them through.
>
> -- 
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Mich

[dspace-tech] Re: Shibboleth on DSpace 7.2 won't work for unknown reasons

[Matthias Letsch]

Hallo Matti,

thank you very much!

This has at least resulted in the 403 becoming a 401 and DSpace noticing 
something about the login attempt, which I consider positive progress.

However, DSpace now complains in the logs that it cannot find the required 
attributes:

2023-06-29 11:58:35,693 ERROR unknown unknown 
org.dspace.authenticate.ShibAuthentication @ Shibboleth authentication was 
not able to find a NetId, Email, or Tomcat Remote user for which to 
indentify a user from.
2023-06-29 11:58:35,707 ERROR unknown unknown 
org.dspace.authenticate.ShibAuthentication @ Unable to register new eperson 
because we are unable to find an email address along with first and last 
name for the user.
  NetId Header: 'SHIB-NETID'='null' (Optional)
  Email Header: 'SHIB-MAIL'='null'
  First Name Header: 'SHIB-GIVENNAME'='null'
  Last Name Header: 'SHIB-SURNAME'='null'
2023-06-29 11:58:35,709 INFO  unknown unknown 
org.dspace.app.rest.security.EPersonRestAuthenticationProvider @ 
anonymous::failed_login:email=null, result=4
2023-06-29 11:58:35,719 ERROR unknown unknown 
org.dspace.app.rest.security.StatelessLoginFilter @ Authentication failed 
(status:401)
org.springframework.security.authentication.BadCredentialsException: Login 
failed

So I guess I need to modify the attribute-map.xml accordingly to match the 
expected attributes under 
[dspace]/config/modules/authentication-shibboleth.cfg. 

The documentation at 
https://wiki.lyrasis.org/display/DSDOC7x/Authentication+Plugins#AuthenticationPlugins-ShibbolethAuthentication
 
provides a template for attribute-map with the attributes that seem to 
match at first glance. 

But unfortunately that alone does not change anything for us. Do you 
possibly know more about this?

Thanks again and best regards
Matthias
Matti Yrjölä schrieb am Mittwoch, 28. Juni 2023 um 18:03:53 UTC+2:

> Hi,
>
> Do you have the attribute attributePrefix="AJP_" set in your 
> ApplicationDefaults (in shibboleth2.xml)?
> I think we had similar problem with that setting as we are using that with 
> older DSpace. 
> Removing the AJP_ prefix and also adding "ShibUseHeaders On" in  
>  and   "/server/api/authn/login"> solved this issue.
>
> There was some discussion in:
> https://github.com/DSpace/DSpace/pull/2651#issuecomment-604902452 
> and
> DSpace 7 Shibboleth Configuration - DSpace - LYRASIS Wiki 
> <https://wiki.lyrasis.org/display/DSPACE/DSpace+7+Shibboleth+Configuration> 
> " The AJP proxy only works (Ben Bosman 
> <https://wiki.lyrasis.org/display/~benbosman>) if shibboleth2.xml 
> *doesn't* contain the attribute *attributePrefix="AJP_"* in 
> the ApplicationDefaults. "
>
> Best regards,
> Matti
>
> On Tuesday, June 27, 2023 at 4:33:20 PM UTC+3 Matthias Letsch wrote:
>
>> Hello,
>>
>> for some reason we won't get Shibboleth working.
>>
>> We have a test IdP and test credentials to log in, but something is still 
>> not working. Our colleague from the IDP side says that the communication 
>> between the Shib Daemon on our Server and the Shibboleth IdP is working and 
>> therefore the tasks from his side are finished for now. But he suspects 
>> that Dspace is not communicating properly with shibd and that we have to 
>> change some configurations.
>>
>> As of now I am able get to the Shibboleth login page and to log in with 
>> the test credentials and to accept the metadata usage, but then there is a 
>> HTTP Status 403 report:
>>
>> HTTP Status 403 – Forbidden
>> --
>>
>> *Type* Status Report
>>
>> *Description* The server understood the request but refuses to authorize 
>> it.
>> --
>> Apache Tomcat/9.0.31 (Debian)
>>
>> Has anyone had this problem and knows how to solve it?
>>
>> Thank you and kind regards
>> Matthias
>>
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/a3a7e624-986c-4b41-8811-0d8535416cd1n%40googlegroups.com.

[dspace-tech] Shibboleth on DSpace 7.2 won't work for unknown reasons

[Matthias Letsch]

Hello,

for some reason we won't get Shibboleth working.

We have a test IdP and test credentials to log in, but something is still 
not working. Our colleague from the IDP side says that the communication 
between the Shib Daemon on our Server and the Shibboleth IdP is working and 
therefore the tasks from his side are finished for now. But he suspects 
that Dspace is not communicating properly with shibd and that we have to 
change some configurations.

As of now I am able get to the Shibboleth login page and to log in with the 
test credentials and to accept the metadata usage, but then there is a HTTP 
Status 403 report:

HTTP Status 403 – Forbidden
--

*Type* Status Report

*Description* The server understood the request but refuses to authorize it.
--
Apache Tomcat/9.0.31 (Debian)

Has anyone had this problem and knows how to solve it?

Thank you and kind regards
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/f05e7971-25fd-42a0-b20e-c8892d7a6a4an%40googlegroups.com.

Re: [dspace-tech] Change image on taskbar

[Matthias Letsch]

Hello Tim and Lewatle,

I would like to follow up on that question. The documentation doesn't fit 
for us unfortunately, because for some reason we don't have config.*.yml 
(in DSpace 7.2) where you could put something under a "themes" section.

We only have a dspace.cfg with the following entry under OpenSearch 
settings:

# location of favicon for service, if any must be 16X16 pixels
websvc.opensearch.faviconurl = http://www.dspace.org/images/favicon.ico

But I want to include a local file under images and not a URL. I don't even 
know if this is the right spot to change it. 

How do I do that now if I am missing what the documentation points to?

Thank you and kind regards
Matthias

Lewatle Johannes Phaladi schrieb am Donnerstag, 27. Oktober 2022 um 
14:00:21 UTC+2:

> Hello Tim,
>
> Thanks a lot, favicon is updated.
>
> Regards,
> Lewatle 
>
> On Wednesday, 26 October 2022 at 18:07:52 UTC+2 Tim Donohue wrote:
>
>> Hi Lewatle,
>>
>> That icon in your browser tab is called the "Favicon" of a site.  We have 
>> documentation on how to change that for DSpace 7 here: 
>> https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Customization#UserInterfaceCustomization-CustomizeFaviconforsiteortheme
>>
>> Tim
>> --
>> *From:* dspac...@googlegroups.com  on behalf 
>> of Lewatle Johannes Phaladi 
>> *Sent:* Wednesday, October 26, 2022 9:18 AM
>> *To:* DSpace Technical Support 
>> *Subject:* [dspace-tech] Change image on taskbar 
>>  
>> Dear DSpace Colleagues, 
>>
>> How to change image that appear on address bar.
>> see this picture :
>>  [image: image_2022-10-26_161722772.png]
>>
>> Regards,
>> Lewatle 
>>
>> -- 
>> 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 dspace-tech...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dspace-tech/9082b31b-f67a-4ae3-b541-bebf54980af5n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/e0bff460-2854-4f48-8e84-992df9a303e4n%40googlegroups.com.

[dspace-tech] Creative Commons License Module: Get rid of jurisdiction

[Matthias Letsch]

Hello there,

I'd like to get rid of the "jurisdiction" section in the CC license module, 
because we already stated cc.license.jurisdiction = de in config/dspace.cfg 
and the selection on the input mask has no effect, it always creates the 
license URI with /de at the end whether you choose Germany or some other 
country (e.g. http://creativecommons.org/licenses/by-nd/3.0/de/). (Same 
with othere preferences, if you choose en-US in the cfg file, it always 
creates it with /us and so on).

So this dropdown menu is unfortunately more confusing and unnecessary for 
users than helpful, and I would like to set the module to work without this 
thing. I haven't found a place where I can remove it. How do I do that?

Thank you and kind regards,
Matthias

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/06577295-5d78-482d-8f43-8dac8a6e3680n%40googlegroups.com.

[dspace-tech] DSpace 7.2.1 OAI-PMH Internal Server Error 500 - Log: "OAI 2.0 wasn't correctly initialized"

[Matthias Letsch]

Hello there,

I am setting up DSpace 7.2 as an institutional repository for a University.

The OAI-PMH interface has some internal server Error. I am aware that there 
are already some threads regarding this topic, but none of them seem to 
quite fit my problem. I did run the ./dspace oai import -c task before and 
that task was "successful". However, the OAI page at 
.../server/oai/request?verb=Identify tells me:

*Whitelabel Error Page*

*This application has no explicit mapping for /error, so you are seeing 
this as a fallback.*
*Thu Jun 15 11:38:39 CEST 2023*
*There was an unexpected error (type=Internal Server Error, status=500).*
*An exception has occurred*

The logs report the errors stated below.

Among those is for example "OAI 2.0 wasn't correctly initialized, please 
check the log for previous errors" --> I honestly don't know how to 
"correctly initialize" OAI 2.0 and I didn't find any previous errors 
regarding OAI. The configuration in /config/modules/oai.cfg seems to be 
okay, also the /config/crosswalks/oai/xoai.xml, but I didn't find a xsl 
stylesheet anywhere (xoai.xml refers to static/style.xsl)

Can anyone do anything with the info here or maybe knows the problem and 
can help me? Thanks a lot!

Kind regards,
Matthias

The logs entries:

2023-06-14 

2023-06-14 10:09:04,418 ERROR unknown 84b90674-ce4a-4030-b1a9-58fde903f366 
org.dspace.app.rest.exception.DSpaceApiExceptionControllerAdvice @ An 
exception has occurred (status:500)
javax.servlet.ServletException: OAI 2.0 wasn't correctly initialized, 
please check the log for previous errors
at (...)
Caused by: 
org.dspace.xoai.services.api.config.XOAIManagerResolverException: 
com.lyncode.xoai.dataprovider.exceptions.ConfigurationException: 
net.sf.saxon.s9api.SaxonApiException: Errors were reported during 
stylesheet compilation
at (...)
Caused by: com.lyncode.xoai.dataprovider.exceptions.ConfigurationException: 
net.sf.saxon.s9api.SaxonApiException: Errors were reported during 
stylesheet compilation
 at (...)
Caused by: javax.xml.transform.TransformerConfigurationException: 
net.sf.saxon.s9api.SaxonApiException: Errors were reported during 
stylesheet compilation
   at (...)
Caused by: net.sf.saxon.s9api.SaxonApiException: Errors were reported 
during stylesheet compilation
   at (...)
Caused by: net.sf.saxon.trans.XPathException: Errors were reported during 
stylesheet compilation
   at (...)

2023-06-14 10:51:25,071 ERROR unknown unknown 
org.dspace.xoai.app.BasicConfiguration @ Not able to start XOAI normal 
cache service.
org.dspace.xoai.services.api.config.XOAIManagerResolverException: 
com.lyncode.xoai.dataprovider.exceptions.ConfigurationException: 
net.sf.saxon.s9api.SaxonApiException: Errors were reported during 
stylesheet compilation
at (...)

2023-06-12

2023-06-12 14:11:52,342 ERROR unknown f46fee61-e391-4da0-b9ea-0b032209a0ac 
org.dspace.app.rest.exception.DSpaceApiExceptionControllerAdvice @ An 
exception has occurred (status:500)
javax.servlet.ServletException: Unable to load XOAI manager, please, try 
again.

-- 
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 dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/0634ebe9-6a91-40f2-b3b5-32d11cd26374n%40googlegroups.com.