On Monday, February 3, 2020 at 3:54:22 PM UTC-5, Mark H. Wood wrote:
>
> The admin. email address and the workflow address are different. My
> only guess is that the authentication rules for ksu.edu are different
> from those for k-state.edu even though they are MXed to the same place.
>
>
No,
On Mon, Feb 03, 2020 at 05:23:31PM +, Jeffrey Sheldon wrote:
> I recently upgraded to DSpace 6 and have noticed different behavior with
> respect to email configuration as seen in DSpace 5.
>
> I'm using a trusted and open SMTP relay which doesn't require authentication.
> Therefore, I
Colleagues, I found the solution.
community-home.jsp and collection-home.jsp files it is necessary to insert
the following line in the header:
<% @ page import = "org.dspace.eperson.EPerson"%>
then you can use the function that validates the logged in user:
// Is anyone logged in?
Thanks, Tim.
That's what make this so curious: That the test-email command will result in a
successfully delivered email and the lack of any discernible notifications in
any logs which reveal problems or association with this issue (including no
other WARN or ERROR entries).
I haven't head
Hi Jeffrey,
You might want to look more closely at the log lines *around* that WARN message
you noted below. They may provide more information about what the problem is
with regards to sending the emails -- especially if you see an ERROR just
before or after the WARN.
The error
Dear colleagues, I need to remove the statistics button from pages where
the user is not logged in.
However, dspace only allows you to enable and disable access, but the
button is visible to everyone.
Does anyone know how to do?
Thanks in advance
--
All messages to this mailing list should
All,
I recently upgraded to DSpace 6 and have noticed different behavior with
respect to email configuration as seen in DSpace 5.
I'm using a trusted and open SMTP relay which doesn't require authentication.
Therefore, I have mail.server populated and mail.server.username and
Hello,
I'm sorry, but you haven't provided enough information here to allow us to help
you out. If upgrading to 5.10 hasn't helped your situation, then it's possible
that the bug at https://jira.lyrasis.org/browse/DS-2602 was not the cause of
the behavior you are seeing.
I'd recommend
I would recommend looking at the DSpace logs when your site starts up to look
for errors reported there. It sounds (to me) like the /server webapp (which
includes the REST API) is not starting/initializing properly. The result you
see should be similar to our DSpace 7 Demo REST API at
Hello,
during Node installation there is a hint:
export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
Use this in a script before the maven run. Or add it to your environment
in a different way.
I hope this helps and kind regards,
Paul Münch
Am 31.01.20 um 21:29
Seems like the newest ffi (1.12.2) is causing some problems, downgrading to
1.12.1 seems to work.
so adding the following lines to dspace/modules/xmlui-mirage2/pom.xml
rubygems
ffi
1.12.1
gem
- Anis
On Monday, February 3, 2020 at 8:41:47 AM UTC, Anis wrote:
>
> Hi, I'm
Hi, I'm trying to compile DSpace 5 with the following command mvn package
-Dmirage2.on=true
The error I get is the following,
ERROR: Error installing
../.m2/repository/rubygems/ffi/1.12.2/ffi-1.12.2.gem:
ERROR: Failed to build gem native extension.
current directory:
12 matches
Mail list logo
