Needs to better support users with existing accounts on thatcamp.org

[amandafrench]

Currently users with existing accounts can't (or at least don't have any way of knowing they can) sign in to thatcamp.org before they register for a new THATCamp. Therefore everyone with an existing account is filling out the whole registration form beforehand when they don't need to, and it's creating issues with multiple user accounts and inaccurate user profile information.

One solution is to add all users on thatcamp.org to main THATCamp site (site ID=1), then put a link to thatcamp.org/wp-login.php on the public registration form & invite people to log in before registering for a new THATCamp. However, currently, when users are approved with the registration plugin, they get added to that site only and not to site 1 even though I've got it set to do that using the New Blog Defaults plugin. Therefore users not on site 1 would need to go back to some old child site for a THATCamp they went to once and log in there in order to get the logged-in version of the registration form on another THATCamp child site.

I dunno: maybe BuddyPress can solve some of this.

[amandafrench]

To clarify the problem: user 'tinafey' registers for THATCamp Testing with the registration form at http://testing.thatcamp.org/registration, and goes and has a great time. Tina Fey decides to go to THATCamp AHA and have a great time in New Orleans, so she registers at http://aha2013.thatcamp.org/register. Tina has to either 1) fill the whole form out again or 2) go back to http://testing.thatcamp.org/wp-login.php to sign in so that she doesn't have to fill out the whole form again. She can't even log in at the central site at http://thatcamp.org/wp-login.php because she's not automatically a member of that site.

Ideal behavior: Tina is nudged to sign in to thatcamp.org if she's already been to a THATCamp, AND she can go to a central place to sign in, not to her previous THATCamp site. If Tina doesn't sign in with her existing account before she registers for a new THATCamp, the new information she has entered in the registration form should probably overwrite info in her existing profile. Currently existing profile information is not overwritten.

[boonebgorges]

I've added some text to the top of the registration form. When a user is not logged in, the text urges them to do so, with a link to the login form that then redirects right back to the registration page (regardless of whether the user is already a user on the current site). When a user is logged in, it gives a brief reminder of who they are.

If Tina doesn't sign in with her existing account before she registers for a new THATCamp, the new information she has entered in the registration form should probably overwrite info in her existing profile. Currently existing profile information is not overwritten

This doesn't seem right to me. From a technical point of view, WP doesn't allow you to create multiple accounts using the same email address. So we would have to either delete the existing user (in order to recreate her), or update the existing user based on the data passed. But either one of these is potentially insecure, as I could overwrite anyone's data just by submitting a registration using their email address.

A safer strategy is proper validation. As a minimum, when a registration is submitted by a loggedi-in user, check to see whether (a) there's already a WP user with this email address. If so, bounce to the login screen before processing data. (b) there's already an unprocessed TC registration with this email address. If so, bounce back to the registration page with a note that says "no need to apply again".

To make this nicer, we could add javascript validation, so that you'd know whether you have an existing account before submitting the form (via an AJAX request sent when you are finished typing your email address). This will take an hour or two of development beyond the server-side validation described above, so let me know how you want to approach.

[amandafrench]

The javascript validation seems best to me, especially since when you say "bounce to the login screen" I'm still not sure what login screen they'd go to. I think it'd be confusing to Tina to be asked to log back in to THATCamp Testing (which maybe happened in 2010) at http://testing2010.thatcamp.org/wp-login.php in order to register for THATCamp AHA at http://aha2013.thatcamp.org/register. That's the main thing I want to avoid, whichever method of validation we use.

[boonebgorges]

They go to the login screen of the current site. In your testing you said you were unable to log in at this link. But I think what you were actually unable to do is visit the Dashboard of that site. My modification sends users to aha2013.thatcamp.org/wp-login.php, and when they log in, they are redirected directly back to aha2013.thatcamp.org/register.

The javascript bit has to happen last. Have to do the server-side stuff first.

On 10/10/12 11:48, Amanda French wrote:

The javascript validation seems best to me, especially since when you say "bounce to the login screen" I'm still not sure what login screen they'd go to. I think it'd be confusing to Tina to be asked to log back in to THATCamp Testing (which maybe happened in 2010) at http://testing2010.thatcamp.org/wp-login.php in order to register for THATCamp AHA at http://aha2013.thatcamp.org/register. That's the main thing I want to avoid, whichever method of validation we use.

— Reply to this email directly or view it on GitHub https://github.com/chnm/thatcamp-registrations/issues/42#issuecomment-9308104.

[boonebgorges]

We're talking about existing users here. People who have WP accounts alreadyon the thatcamp.org network, but are not yet members of the specific thatcamp site. But login itself is network-wide.

Amanda French notifications@github.com wrote:

But if they haven't registered yet, they can't log in to the current site.

— Reply to this email directly or view it on GitHub.



[amandafrench]

Just tested it. :) The redirect will help a lot -- definitely don't want people to get stuck on the "Error" page that says "You attempted to access the "Testing" dashboard, but you do not currently have privileges on this site."

Sorry, thought you were offering me two different methods of validation rather than a cherry on the sundae. If you could, please do the server-side stuff first and let me test it. We probably don't need the AJAX suggestion, but I'll let you know after testing.

[boonebgorges]

There was a small bug in the redirect url that may have affected your ability to test this properly. Please give it another go, and see if it's a good enough solution. I can do the JS stuff, but it's a bit time-consuming.

[amandafrench]

I just tested the registration form, and there seems to be a small bug. I created the user henrykissinger with the email address henrykissinger@thatcamp.org on the network, not adding the user to any site, then registered with that email address on testing.thatcampdev.info without logging in. When I approved the registration, the user didn't get added. This might have been because henrykissinger wasn't a member of any site: he was just a user on the network.

I added the user henrykissinger to the site lust.thatcampdev.info and then changed the registration to Pending and then Approved again, but he still didn't get added as a user on testing.thatcampdev.info.

I then created the user hillaryclinton as a member of lust.thatcampdev.info with the email hillaryclinton@thatcamp.org and filled out the registration form without logging in. Approving that registration did successfully add Ms. Hillary as a user to the site, and it kept her existing profile data instead of overwriting it with the registration form data, which is good (we decided).

[UPDATE: This is unrelated to whether a user is a member of a site already: it's an issue with approving users from the batch edit screen versus from the individual application screen.]

[amandafrench]

I will close this issue and make a new one, since at least 1) there's a login nudge, and 2) users who are members of existing sites seem to be added properly. That solves most of this issue.