IQSS / dataverse

Open source research data repository software
http://dataverse.org
Other
881 stars 492 forks source link

SignUpUrl behavior #3396

Closed donsizemore closed 8 years ago

donsizemore commented 8 years ago

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.

pdurbin commented 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:

screen shot 2016-10-03 at 3 40 37 pm

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:

screen shot 2016-10-03 at 3 51 26 pm

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.)

donsizemore commented 8 years ago

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

pdurbin commented 8 years ago

@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

mheppler commented 8 years ago

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.)

donsizemore commented 8 years ago

@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.

mheppler commented 8 years ago

@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.

  1. From the Root Dataverse, click the Sign Up link in the navbar to navigate to the Create Account pg.
  2. While on the Create Account pg, you'll notice the URL contains the following query string parameter redirectPage=%2Fdataverse.xhtml. _Click the Sign Up link in the navbar again._
  3. The Create Account pg reloads, and you'll see that the redirectPage query string parameter now reads redirectPage=%2Fdataverseuser.xhtml. Fill out the form, all the required fields, then click the Create Account button.
  4. You are now logged in into your new account, and land on the Account pg, and not the Root Dataverse pg.

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.

mheppler commented 8 years ago

@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.

donsizemore commented 8 years ago

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!

scolapasta commented 8 years ago

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= .