[dspace-tech] How to change other user's password

2019-01-25 Thread librarysystems . test
I would like to propose that a method for changing a user's DSpace password 
be added to the DSpace admin tools.  I know it is possible to change a 
password using the "forgot password" link, but that requires access to the 
user's email.  In addition, it requires access to the "forgot password" 
link, which does not show up when the system uses only Shibboleth 
authentication.  In this case, a user that is actually a program signing 
into the Sword module might use DSpace password authentication, even though 
that option is not available on the web interface.  So in order to get the 
"forgot password" link, an administrator must enable password auth and 
produce an authentication menu which might confuse a normal user.  If the 
program's email address is a list serve group, the members of the group 
have to be notified in advance not to click on the "reset password" link in 
the upcoming email.  Finally, if the recipient is unlucky enough to have 
Microsoft Outlook Safelinks, the "reset password' link might not work at 
all.

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


[dspace-tech] Re: Suddenly Sword Says "Unauthorized Credentials"

2019-01-25 Thread librarysystems . test
This problem was caused by the Sword configuration on the DSpace server.  
Or, more precisely, the complete lack of configuration of the Sword 
module.  We moved the server from another host last summer, and that must 
be when the config got overwritten with the defaults.  Apparently, no one 
had tried to publish from Vireo until last week!  Once the Sword module was 
correctly configured, Vireo was able to connect.


On Thursday, January 24, 2019 at 4:30:54 PM UTC-6, librarysy...@gmail.com 
wrote:
>
> Further information:
>
> We seem to have got past "unauthorized credentials."
>
> Now Vireo says, "Unable to communicate with deposit location: 
> org.purl.sword.client.SWORDClientException: Received error from service 
> document request: Code: 400, Message: 'Bad Request'
>
> Using curl to browse to the Sword servicedocument URL gives this message: 
> "The requested URL /sword/servicedocument was not found on this server."
>
> Browsing to the same URL in Internet Explorer gives this message:  HTTP 
> Status 400 – Bad Request
> --
>
> *Type* Status Report
>
> *Message* Unable to recognise URL as a valid service document: 
> https://rctest.ourschool.edu/sword/servicedocument
>
> *Description* The server cannot or will not process the request due to 
> something that is perceived to be a client error (e.g., malformed request 
> syntax, invalid request message framing, or deceptive request routing).
> --
> Apache Tomcat/7.0.90
> - show quoted text -
>
> On Wednesday, January 23, 2019 at 10:55:26 AM UTC-6, 
> librarysy...@gmail.com wrote:
>>
>> We are using Vireo 3.0.6 (with Sword v1) and publishing to a DSpace 6.3 
>> repository.  Since updating the operating systems on both servers, Vireo 
>> can’t connect to the DSpace repository to deposit theses and 
>> dissertations.  The DSpace server is running Amazon Linux kernel 
>> 4.14.88-72.73.amzn1.x86_64, Tomcat 7 and Apache 2.2.  At first, the error 
>> message indicated a certificate error.  I replaced the cacerts files and 
>> the operating system CA files with the ones that existed prior to the 
>> update.  That fixed the certificate error, but now we get “unauthorized 
>> credentials” when testing the connection.  I tested the credentials by 
>> logging into the DSpace server’s web interface, and they are correct.  User 
>> permissions have not changed, so the deposit user should be authorized.
>>
>>
>> I also tested by browsing to the Sword servicedocument page.  The page 
>> produces a login box.  When I enter the credentials, the login box 
>> disappears, then reappears.  I don't know how to interpret this.  The 
>> Tomcat log records 401 errors.
>>
>>
>> I'm out of ideas for troubleshooting, would appreciate any suggestions.
>>
>>
>> Glenn
>>
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


[dspace-tech] Harvesting a DSpace 6.3 OAI server from a Dspace 5.10 client

2019-01-25 Thread Diego Brice
Hi!. I have problems trying to 
harvest my DSpace 6.3 server. This is my scenario:


I have a DSpace 6.3 repo with many communities and collections running in 
an intranet environment. Some of those collection are private, so there is 
no anonymous access. Some of the "public" collections must be shared with 
outside people so this is the first problem I have to solve. Because there 
is no way to hide communities and collections (I mean, you see the 
collection listed and I don´t want to let the outside user know  that there 
is a private collection) I thought that the best way to achieve this is to 
have a second server where I create only those communities and collections 
that are public and harvest records and documents from the main DSpace 
server.

After installing a second 6.3 server I got the second problem. There is an 
unresolved bug that doesn´t allow to harvest both the record and the files. 
You can see it here: 
https://jira.duraspace.org/browse/DS-4028
https://groups.google.com/d/msg/dspace-tech/95xmbswHxW0/CEPvzWVvCAAJ

After thinking that the problem was related with the DSpace 6.3 OAI client 
I downgrade my second server to DSpace 5.10 but when I create a collection 
and begi to harvest, I get the following:

2019-01-24 16:42:45,221 INFO  org.dspace.harvest.OAIHarvester @ Collections 
ready for immediate harvest: [1]
2019-01-24 16:42:45,226 INFO  org.dspace.harvest.OAIHarvester @ Thread 
queued up: Thread[Thread-159,5,main]
2019-01-24 16:42:45,226 INFO  org.dspace.harvest.OAIHarvester @ Thread 
started: Thread[Thread-160,5,main]
2019-01-24 16:42:45,226 INFO  org.dspace.harvest.OAIHarvester @ Thread for 
collection 1 starts.
2019-01-24 16:42:45,285 INFO  org.dspace.harvest.OAIHarvester @ HTTP Request
: http:
//./oai/request?verb=ListRecords&until=2019-01-24T19:42:45Z&set=col_123456789_2076&metadataPrefix=oai_dc
2019-01-24 16:42:45,292 INFO  org.dspace.harvest.OAIHarvester @ Found 35 
records to process
2019-01-24 16:42:45,299 ERROR org.dspace.harvest.OAIHarvester @ Harvesting 
error occurred while processing an OAI record: OAI server returned the 
following errors during getDescMD execution: [idDoesNotExist]
2019-01-24 16:42:45,302 INFO  org.dspace.content.Collection @ anonymous::
update_collection:collection_id=1
2019-01-24 16:42:45,304 WARN  org.dspace.core.Context @ anonymous::
restore_auth_sys_state:not previous state info available null
2019-01-24 16:42:45,305 INFO  org.dspace.harvest.OAIHarvester @ Thread for 
collection 1 completes.
2019-01-24 16:42:46,229 INFO  org.dspace.harvest.OAIHarvester @ Done with 
iteration 34


I cleared OAI cache in the main server, reimported, restarted Tomcat but 
nothing changed. It only works when I harvest only the records.

So, what else could I do?.
Where is the problem?
How could I have a second instance to publish only those non private 
collections without manually export from server A and importing in server B?

Thank in advance

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


[dspace-tech] Re: DC, QDC, and DCTERMS: reviewing our metadata practices

2019-01-25 Thread Mark H. Wood
On Thursday, January 24, 2019 at 9:10:06 AM UTC-5, Alan Orth wrote:
>
> We have started looking at our use of metadata across our repositories and 
> I have to say that it is very confusing! First some background as I 
> understand it, then the current state of affairs in DSpace 4/5/6, and then 
> my question(s). :)
>
> Dublin Core is the original specification of fifteen elements from 
> 1995[0]. It was amended in 2000 to add element qualifiers like 
> "dc.date.issued" as well as a few new elements[1]. These were both 
> superseded in 2008 with the introduction of the Dublin Core Terms (aka 
> DCTERMS) specification[2], which essentially combines both of them.
>
> By default DSpace makes heavy use of both simple and qualified Dublin Core 
> in its input forms, but also provides crosswalks to translate many of these 
> to DCTERMS that are then exposed as metadata in the XMLUI[3][4]. It is very 
> easy to change the input forms to use different fields and even custom 
> namespaces, though some core fields seem to be dangerous (like dc.date.* 
> and dc.contributor.author).
>
> Our repository is consumed ravenously by search engines, but also by 
> increasingly many harvesters via REST and OAI APIs. If we want to make sure 
> that the metadata these harvesters receive is also standards compliant and 
> interoperable, shouldn't we update our input-forms and existing item 
> metadata to take some of the crosswalks into mind? For example: to start 
> using dc.language or dcterms.language instead of dc.language.iso (I would 
> of course update the crosswalks accordingly). Does any of this change in 
> DSpace 7? Is there any talk of moving away from a flat schema so that 
> authors and institutions could be related, for example?
>
>

I agree that too little attention is given to interchange, and how careful 
we have to be to make M2M communication meaningful without introducing 
errors and unwarranted assumptions.

Since it appears to me that there is no such thing as dc.language.iso, 
using dc.language makes sense.  There are several DSpace inventions 
masquerading as QDC.  Some of them should be moved to a different 
namespace.  No, I haven't yet made a table of my recommended changes.

There is always talk of moving away from a flat namespace.  I think this 
may be unnecessary.  Authors, for example, are not contained by 
institutions; an author writing for or with the sponsorship of an 
institution should cause the authorship of the work to be marked with a 
relationship to the institution -- that is:  an object references another 
by unique identifier.  It may be convenient to express this externally with 
a hierarchial form (e.g. in METS), but that is merely for interchange; 
internally we should represent knowledge more flexibly so that we can 
produce whatever external representation is required without having to 
reverse too many assumptions.  An author's employment and membership 
history would properly belong in a biographical repository, which (were 
such a thing to exist) would have quite a different sort of metadata 
structure.  Given a sufficiently rich set of simple types, most of what we 
know about an author or a work or an institution should be usefully 
representable as simple lists.

We also need to look at enriching our internal representation, but in a 
different way.  I think it was Mark Diggory who observed that we talk about 
"metadata schemas" as if we had them, but what we really have is 
namespaces.  A schema not only tells you what fields are defined and how 
they are named, but what kind of data a field may hold and what values of 
that kind are acceptable.  A well-written schema will guarantee that the 
value stored in a field will make sense.  If we declare that 
dc.date.accessioned is a date, then even if the UI mistakenly accepts a 
value of "Louisiana" as a date, the metadatavalue service would not, 
because that can't be understood as a date.  We might store the value of 
dc.date.accessioned as a string encoding of a date, but then we might store 
it as a serialized Calendar, and the schema then tells us how to interpret 
the byte array and informs external interfaces of how they might represent 
the field's value.  Another way of looking at this is that we encode 
information in form definitions which might be pushed into the metadata 
schemas (if we had them) and fetched by the form interface, allowing us to 
simplify the writing of forms.

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://

[dspace-tech] Re: Hiding communities/collections from unauthenticated users.

2019-01-25 Thread Diego Brice
IIja, did you finally manage to do this? How?.

El miércoles, 14 de septiembre de 2016, 9:40:08 (UTC-3), Ilja Sidoroff 
escribió:
>
> I'm trying to hide some internal communities and collections from 
> unauthenticated users (with DSpace 5.5/XMLUI, but also with upcoming 6.0). 
> How-to in the Wiki has been outdated (
> https://wiki.duraspace.org/display/DSPACE/Hide+Community+or+Collection+from+list)
>  
> and some other googling turned out advise to filter specific 
> communities/collections in xsl, which I think is prone to breakage in 
> migrations and such (e.g. 
> http://stackoverflow.com/questions/37122851/hiding-collections-and-sub-collections-in-dspace).
>  
>
>
> What I'd like to do is to filter the community/collection list when it is 
> generated. This seems such common requirement, that it might have been 
> implemented already by someone? 
>
> br, 
>
> Ilja Sidoroff 
> University of Eastern Finland 
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


[dspace-tech] Alexa Certify Javascript on Dspace

2019-01-25 Thread Nugroho Raharjo
Dear All

How i can insert Alexa Certify Javascript in my Dspace header?
I use Migare2 as my theme. Please help me.

Thanks

-- 


*I N T E G R I T Y | P R O F E S S I O N A L I S M | E N T R E P R E N E 
U R S H I P*





**UNIVERSITAS CIPUTRA***
CitraLand CBD Boulevard*


*Surabaya 60219, INDONESIA
T. (62-31) 745 1699*

*F. (62-31) 745 1698*


*www.uc.ac.id *


 

Disclaimer: The contents of this 
email along with its attachments are intended for the recipient only and 
may contain information that is legally privileged, confidential and exempt 
from disclosure. If you are not the intended recipient, you are hereby 
notified that any dissemination and distribution of this email along with 
its attachments are strictly prohibited. If you have received this message 
in error, please delete this email from your computer. Universitas Ciputra 
will not be responsible for any damage caused by this email.

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


[dspace-tech] Custom Thumbnails

2019-01-25 Thread Vusani Mutshinya
Good day,

While I am still writing a Video Filter module for thumbnails, our 
organization wants to use more appropriate "placeholder" icons (e.g. for 
videos display a video icon and for audio, audio icon)
I have been able to edit the *item-view-xsl *file to achieve the above, but 
only if one multimedia file is in show. If I have both video and audio as 
items on the same submission; my code fails by only displaying the icon of 
the first file for the rest. This means that the mimetype variable I use is 
load only once. My hope is to get it to reload with each individual file.

See below code:































How can I get the "mimetype" variable to load per file. If there is a more 
efficient way please point me to it.

Regards
Vusani
Parliament RSA

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.