Hi,
> it appears that I can no longer respond to a request without being logged
> in(?).
Just to provide an update on this for the archives/anyone who is interested . .
.
>From a review of the "Request a copy" code in v4.2, it looks like that version
>was supposed to work in the same way (?), i.e. requiring the user responding
>to the request to log on, so perhaps the "bug" was with v4.2, and is now
>"fixed" in v6 (? Guessing a bit, though, so happy to be corrected).
Either way, I was able to work around this "feature" by adding lines to turn
authorization off prior to retrieving the bitstream that the code was trying to
retrieve, and then turning it back on again afterwards - so, in
RequestItemServlet.java, I now have the following in the midst of the
processAttach method (in the section that is trying to send a single file):
} else {
// Turn off authorizations to fetch file - MW: 12/12/17
context.turnOffAuthorisationSystem();
Bitstream bit = requestItem.getBitstream();
email.addAttachment(bitstreamService.retrieve(context, bit), bit.getName(),
bit.getFormat(context).getMIMEType());
// Turn authorizations back on - MW 12/12/17
context.restoreAuthSystemState();
}
However, I also noted issues when trying to request "All files" - in this case,
the "if" statement wasn't detecting that the user had actually requested all
files - so I had to extend the "if condition" that tests for this, so that it
became:
// Additional check of request's "isAllFiles" flag added - MW: 12/12/17
if (requestItem.getBitstream() == null || requestItem.isAllfiles()) {
- and then, once into the body of this if statement and looping through
available bitstreams, the check to see if the bitstream in question has
Anonymous READ permissions was also not working - and it looks to me like it
needed to be inverted, so this if statement becomes:
if (!bitstream.getFormat(context).isInternal()
&& !authorizeService.authorizeActionBoolean(context, null, bitstream,
Constants.READ, false)) {
[I added the "!" in front of "authorizeService.authorizeActionBoolean( ...)]
I've tested these changes, and it now appears that an Author can respond to a
"Request a copy" request without logging in, and the "All files" option is also
now working as expected (tested with a record with multiple files, some of
which were embargoed, and some that weren't, and only the (multiple) embargoed
files were emailed to the requester). I also tested both scenarios when the
responder was logged on, and when they weren't.
I would be interested to know if others who are using the Request a copy
functionality in v6 have noticed issues when a user requests "All files", and
also if you've noticed a change in behaviour with respect to the responder
needing to log in before the email actually gets sent?
Hopefully I've not done anything too controversial here but if anyone spots any
issues with any of my thinking, or what I've done to resolve the issues I
believe I've been seeing, then please feel free to let me know :)
Cheers,
Mike
Michael White
Senior Developer
Business Applications and Integrations
T: (01786) 466877
E: [email protected]<mailto:[email protected]>
A: G5, Airthrey Castle, University of Stirling, Stirling, FK9 4LA
From: Michael White
Sent: 11 December 2017 16:15
To: [email protected]
Subject: DSpace v6.2, Request a copy: Can't respond to request without logging
in?
Hi,
I'm in the process of setting up a DSpace v6.2 DEV system (JSPUI) and I've been
testing the "Request a copy" functionality . . .
However, from what I've seen, it appears that I can no longer respond to a
request without being logged in(?).
I.e. if I receive a "Request a copy" email, click the link to open the "Don't
send a copy" or "Send a copy" page, click "Send a copy", and then click the
"Send" button on the "Accept the request" page, I'm then challenged to log in
before the email will actually be sent - i.e. I'm taken to the login page, and
then, once logged in, I'm then sent on to the "Your request was sent
successfully!" page (and the email is finally sent) - if I don't log in, the
email does not get sent.
This is different to the behaviour we have in our current v4.2 system - there,
a user can click the email link and "Accept" the request (stepping through the
pages) and the email with the file is sent (and the user redirected to the
"Your request was sent successfully!" page), all without having to log on.
Am I correct in my assumption that in v6 the user is now required to log in in
order to complete their response to a "Request a copy" email? If so, is there
any way to disable this and revert to the v4.2 behaviour?
All deposit to our repository is from our CRIS system (with the request a copy
email address held in metadata where appropriate), so our users don't usually
have to log in to our Repository for anything, so I'd really rather they didn't
have to do it in order to respond to these requests? (Plus, as this is changed
behaviour for our users, I'm concerned that our staff won't bother to log in,
just assuming that the email has been sent as they've clicked the "Send" button
- thus there is a real danger that files won't actually get sent).
I'm currently reviewing the code (in v4 against v6) to see if I can work out
how to turn the authentication/authorisation off, but I'm guessing a little, so
if anyone has any thoughts how to achieve that, please let me know!
Any observations/suggestions welcome as I really need to avoid the logging in
step if at all possible.
Cheers,
Mike
Michael White
Senior Developer
Business Applications and Integrations
T: (01786) 466877
E: [email protected]<mailto:[email protected]>
A: G5, Airthrey Castle, University of Stirling, Stirling, FK9 4LA
--
The University achieved an overall 5 stars in the QS World University Rankings
2016/17
The University of Stirling is a charity registered in Scotland,
number SC 011159.
--
You received this message because you are subscribed to the Google Groups
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
