Closed donsizemore closed 8 years ago
I tried to reproduce this behavior on http://phoenix.dataverse.org running v. 4.5.1 build 57-origin/develop-d601f27 and I guess I'm confused about what this issue is about. That server has the default setting for curl http://localhost:8080/api/admin/settings/:SignUpUrl
which is {"status":"OK","data":{"message":"/dataverseuser.xhtml?editMode=CREATE"}}
. It has a published dataset. When I create a new user ("foobar1") the user is directed to the homepage and sees some published data like this:
Now, if I then click "My Data", I do see "Sorry, nothing was found for these roles: Admin, File Downloader, Dataverse + Dataset Creator, Dataverse Creator, Dataset Creator, Contributor, Curator, Member" but this is a normal message since the user doesn't have any data yet:
In summary, I think the out of the box redirect behavior for a new user local user is correct. Or are you talking about Shibboleth users, @donsizemore ? (I don't recall :SignUpUrl
affecting Shibboleth users though.)
Hi Phil,
So, in our case we renamed the root dataverse (to unc aka /dataverses/unc). If I created a local user, on form submission I was directed to the "My Data" tab and received the not-really-an-error above. I set SignUpUrl thinking it would redirect new accounts to /dataverses/unc, as the guide says "to which users will be sent after signup" but instead it directed the Sign Up tab to /dataverses/unc?redirectPage=%2Fdataverse.xhtml , which is not found.
Now on a test box I'm not getting the redirect to "My Data" as I was on dataverse.unc.edu, and... eh, I'll close the issue. If it comes up again someday, I'll try to do more troubleshooting.
Thank you for your help, and sorry for the noise. D
@donsizemore ok, no worries. By the way, instead of /dataverses/unc
it may have worked if you had used /dataverse.xhtml?alias=odum
for :SignUpUrl
but that's an uglier URL. I haven't tested this myself. To get the "pretty" URLs we use something called PrettyFaces. Here's where we map "dataverse.xhtml" to "dataverse": https://github.com/IQSS/dataverse/blob/v4.5/src/main/webapp/WEB-INF/pretty-config.xml#L6
Question, @donsizemore. Is this, /dataverses/unc?redirectPage=%2Fdataverse.xhtml
the exact URL that you tried forwarding to? Because that would return a Page Not Found error due to the plural dataverses
in the URL. That is incorrect. It should be singular, dataverse
, as you can see this URL, https://dataverse.harvard.edu/dataverse/odum
, for the ODUM Harvested Dataverse in the Harvard Dataverse.
(H/T to @pdurbin for mentioning PrettyFaces which clued me into double checking that URL format in that previous comment.)
@mheppler whoops! that was my typo this morning. I gave it /dataverse/unc just now which results on my test machine as https://dataverse-test.irss.unc.edu/dataverse/unc?redirectPage=%2Fdataverse.xhtml%3Falias%3Dunc (no 404, but no sign-up page either, just the contents of the UNC dataverse).
All I'm really after is avoiding new users seeing the 2nd screenshot on sign-up (which is what I remember seeing when I created my Shibboleth account to test) but if the defaults work well for you all, absolutely leave them as-is.
@donsizemore + @pdurbin -- This issue didn't sit with me, and this morning I set out to reproduce it, and succeeded. On the same http://phoenix.dataverse.org/ machine that Phil tested it. Here is how I reproduced the issue Don initially reported.
redirectPage=%2Fdataverse.xhtml
. _Click the Sign Up link in the navbar again._redirectPage=%2Fdataverseuser.xhtml
. Fill out the form, all the required fields, then click the Create Account button.I will discuss this with @scolapasta who developed the redirectPage logic, to see if something can be done to avoid this, or if the redirect logic working as expected in this use case.
@donsizemore -- I'd also like to get more details regarding accessibility issues with the error and warning message blocks. Feel free to open a new GitHub issue to report on those, so that we can address them, and try to improve them.
Good morning, @mheppler you said better than I what I had to say. The only thing I could add would be that setting the sign-up url to point to the root dataverse (in our case /dataverse/unc) broke the link to the SignUp page. Thinking through steps 3 and 4 is essentially what I was reporting. Thank you!
It's possible this may be something related to introducing a bug during a previous refactoring:
https://github.com/IQSS/dataverse/issues/3225
After reading the details there, I'm not quite sure, without further investigation.
On Wed, Oct 5, 2016 at 10:30 AM, Don Sizemore notifications@github.com wrote:
Good morning, @mheppler https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mheppler&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=xgAtlRJhZJjMyKX1J660N0IQRNfpw7XyvKRWo-rQjyo&m=WotHCtVW1qdX1aAPFd5IcgbkzbFhwA8NZQ_5fyfs8mI&s=VpEDJXkQigUmEwlRakCoLBGInqmW6SZH9xP9wSnKNME&e= you said better than I what I had to say. The only thing I could add would be that setting the sign-up url to point to the root dataverse (in our case /dataverse/unc) broke the link to the SignUp page. Thinking through steps 3 and 4 is essentially what I was reporting. Thank you!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IQSS_dataverse_issues_3396-23issuecomment-2D251691735&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=xgAtlRJhZJjMyKX1J660N0IQRNfpw7XyvKRWo-rQjyo&m=WotHCtVW1qdX1aAPFd5IcgbkzbFhwA8NZQ_5fyfs8mI&s=tOGeGomLTtYCDAVvZVTS_NaIAz7bSBEydtGCvkI3lSU&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AEEhBG588rUuU5xurbxKkEWRC-2DO8F1WYks5qw7SdgaJpZM4KM5yT&d=CwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=xgAtlRJhZJjMyKX1J660N0IQRNfpw7XyvKRWo-rQjyo&m=WotHCtVW1qdX1aAPFd5IcgbkzbFhwA8NZQ_5fyfs8mI&s=LO_NT44Gwk77FCH8_CDHfJBhPApfjcJlEIH-OWMrSX0&e= .
The default SignUpUrl, to which users will be sent after signup, worked fine for us but in our installation a new user owned no dataverses, datasets or datafiles and so his/her/zher first impression was a red/orange (I'm colorblind) error stating "No data found to show for these roles:
"
I set it to our root dataverse via the API, but it seemed to break our SignUp page off our homepage (would display our root dataverse without the trailing /dataverseuser.xhtml?editMode=CREATE I set it back to the default and we're again in good shape.
As an aside, the documentation for this API call contains an errant "true" which, if blindly copy-pasted by someone such as moi returns a 404 for the sign-up page. I'll submit a pull request for that in a second.