(proposal to) automatically link user and author page slugs on creation

[eplebel]

this is to ensure that the following 2 requirements can be achieved (which are necessary for the crowdsourcing platform to work and grow):

1. user names (displayed publicly and to the logged-in user themselves) need to be unique for reputational dynamics to work
2. admins need to be able to create author pages (so that we can lure in prominent transparency mavericks by first [partially] curating their author pages and then inviting them to the platform). indeed, this is precisely what i'm doing right now for Lorne Campbell's and Daniel Lakens' author pages.

relevant discussion from #14 :
Alex:
here's a thought: What if creating an author page automatically created a linked user account, and vice versa? Then when you invite the user and they accept, their user account and author page are already linked and waiting for them, they would just need to set their password and start curating. This way, a given person's username and author slug would always match because they'd always be created at the same time, and they wouldn't need to decide between creating a new author profile vs searching for and linking one that you already created for them.

The only downside I can think of is that the users who don't need an author page would still have one, but in my mind that's OK because they could just not fill it out or link any articles to it.

I think this would work fine for both flows:

1. You (an admin) invite someone you haven't created an author page for. You enter their e-mail and full name. A User, Author, and Invitation are simultaneously created, linked and saved. They click the link in the e-mail, choose a password, and log in, and their profile is there waiting for them.
2. You (an admin) create an author page for someone, entering their full name. User and Author objects are simultaneously created, linked and saved. Later, you invite them, and enter their e-mail address. An Invitation is created and linked to the existing User and Author objects, and the invite e-mail is sent. They click the link in the e-mail, choose a password, and log in, and their profile is there waiting for them.

Etienne:
yes i think your proposed approach (of automatically/simultaneously creating/linking user and author page) is a good one.

however, i still think it may not cover an edge case whereby an admin creates an author page, but then that person signs up before being invited by the admin (or somehow gets invited but doesn't click the invite link). for this edge case, the user would need to be able to claim a pre-existing author page and then any (non-redundant) articles on that pre-existing author page would be merged into their newest author page.

for example, admin creates author page for "steve-smith", but doesn't invite him. later, that same person signs up under "steve-smith-2". the user then realizes that the "steve-smith" author page is his, and claims the author page. all (non-redundant) articles from pre-existing "steve-smith" author page are merged into his "steve-smith-2" author page, and the "steve-smith" author page is deactivated (or could even re-direct to "steve-smith-2" author page; but any one searching for "Steve Smith" would only be displayed the correct activated "steve-smith-2" author page.

so in summary, it appears we need the following new functionality:

1. automatic/simultaneous creation/linking of user and author page (having same slug)
2. allow user to claim pre-existing author page
3. author page merge tool (merging all non-redundant articles of pre-existing author page into newest author-page)

well let me know what you think.
this of course involves a non-trivial amount of work, but the good news is that we only need the stuff in
# 1 for now and can implement # 2 and # 3 later (given that the 1st group of early beta testers won't be allowed to invite new users and non-invited users won't be able to sign-up until way later).

[eplebel]

i labeled this "high priority" because a solution to address this issue might mean that we need a fresh production DB.
(and so i've halted seeding the production DB for now).

[alexkyllo]

As part of this change, I want to merge UserProfile and Author into one model and drop the author slug field, since it's become redundant with the username. Having two fields that are required to always match is silly, if we can simply use one field instead.

The edge case you mentioned is valid, but hopefully rare. A tool to bulk transfer article linkages from one user/author to another should be easy to implement later, if and when it's needed. It's probably only really needed after that edge case actually happens more than a couple of times, because there is an obvious manual workaround.

@onejgordon what's your take on this proposal? It would have some impacts on the UI design, for example we'd need to remove the option to create or link an author page for non-admin users, since they'd no longer need to do that--every user would automatically get an author page. And admins would probably need some sort of UI to invite an existing user/author, as opposed to inviting someone who doesn't have a user/author account created for them yet. We would also need to redirect the invite e-mail to a "set password" page rather than a signup page.

[eplebel]

for example we'd need to remove the option to create or link an author page for non-admin users, since they'd no longer need to do that--every user would automatically get an author page.

quick comment: correct, but we'd still want the ability for users to activate their author page because a sizable minority of users will never have a non-empty author page (e.g., users who are unpublished undergraduate students, research assistants, or even unpublished graduate students).

[alexkyllo]

Sure, I think we could easily flip an "is_activated" bit that just controls whether to display an author page for a given user, hiding the fact that there's no difference between a user and an author in the database.

[onejgordon]

This sounds like a big improvement. I was not in favor of the redundancy in the prior design, and think this resolves it. Yes as @eplebel mentions we can just turn the 'create my author page' UI to 'enable my author page', with a toggle (assuming we are OK with people deactivating their page at a later time).

[eplebel]

turn the 'create my author page' UI to 'enable my author page', with a toggle (assuming we are OK with people deactivating their page at a later time).

i need to think more about whether we actually want to let users "deactivate" their enabled author pages (leaning toward no given no clear use case for this). so for now, we can actually just keep the same language (because from their perspective, they are "creating" their author page).

need to redirect the invite e-mail to a "set password" page rather than a signup page.

but this is still "signing up" from the user's perspective right? so i think we can just keep the signup page as is.

I want to merge UserProfile and Author into one model and drop the author slug field, since it's become redundant with the username

but just to confirm: each user will still have user settings, # of invites, user contributions, etc., so perhaps it's still better (in terms of organization) to keep UserProfile and Author models as distinct (but linked through the unique user name slug)?

also, we'll eventually have user pages: clicking on a user name will bring you to their user page, which will display their recent contributions, etc. and a link to their author page, if it has been enabled. (hovering over a user name could also show a link to that user's author page if it's been enabled.)

admins would probably need some sort of UI to invite an existing user/author vs. inviting someone who doesn't have a user/author account created for them yet.

"Invite Page" changes
correct, we'll need these 2 admin functionalities:

1. invite user with pre-enabled author page
2. invite user with author page not yet enabled

mockup:

radio button for scenario 1 enabled by default.
(we could have also just added an optional "User name/Author page URL" text field on the invite page, and made the "Full Name" field optional (for scenario 1), but this got kind of confusing.)

"Create" Author Page" changes
finally, we may need to slightly change the "Admin Create Author Page" to allow:

1. creating/enabling an author page for new user
2. creating/enabling an author page for pre-existing user (edge case)

mockup:

radio button for 1st scenario enabled by default.

[alexkyllo]

Thanks for taking the time to think through these scenarios @eplebel

but this is still "signing up" from the user's perspective right? so i think we can just keep the signup page as is.

This got me wondering if there any ethical or legal implications related to creating accounts on behalf of users who haven't signed up or accepted an invitation. On second thought, it may actually be problematic from a privacy perspective to create a user account for, and store personally identifiable information on behalf of, a user who hasn't taken any action to initiate a signup. I also can't think of another website that does this.

but just to confirm: each user will still have user settings, # of invites, user contributions, etc., so perhaps it's still better (in terms of organization) to keep UserProfile and Author models as distinct (but linked through the unique user name slug)?

Yes--those fields are unused currently, so I was wondering if they could be removed, good to know that you still plan on making use of them in a future version. We can still have multiple one-to-one models linked together, without duplicating the slug field.

Thinking through the flows again:

1. User initiates signup, user may or may not create own author page
2. Admin invites user, user accepts invitation, user may or may not create own author page
3. Admin creates author page for user, invites user, user accepts invitation, user already has an author page

1 is not going to be enabled for a while. 2 is straightforward. 3 is what we're concerned about here, because it has some potential failure modes we've identified. But I think that when you create an author page, invite the user that that author page is for, and they accept and sign up, if we can guarantee that the user account they create will always be automatically linked back to the author page you created, then it will be fine. You'll just need a UI to select which author you're inviting at the time you create the invite, as your mockup indicates.

To make this work, I think I will store the slug on the UserProfile model, an instance of which will be auto-created whenever either an Author is created or a User signs up.

Then the Author instance doesn't need to be created until the admin or the user creates it. If you do select an Author at the time you create an Invitation, then the Author and Invitation will be linked at that time, and the signup will create a User that's linked to the Invitation and transitively to the Author and UserProfile/.

The actual username on the User model can always be the e-mail address, which the user supplies at the time of signup (though the e-mail form field is auto-populated from the Invitation instance). In the URL patterns, we can use the same slug field for both /accounts/<slug>/ and /authors/<slug>/ and we can always display the slug instead of the e-mail address.

[eplebel]

it may actually be problematic from a privacy perspective to create a user account for, and store personally identifiable information on behalf of, a user who hasn't taken any action to initiate a signup. I also can't think of another website that does this.

actually, we won't be storing any personally identifiable information for authors, so this won't be an issue. all of the information is already public, because this is required as a public intellectual/researcher. it's like creating a Wikipedia page for a researcher and listing their name, position, affiliation, publications, etc. (even email address is considered non-private information for researchers given that it is publicly listed within article PDFs and online for HTML-versions of online articles (e.g.)

In the URL patterns, we can use the same slug field for both /accounts// and /authors// and we can always display the slug instead of the e-mail address.

but when we'll later have user pages, i assume we'd also have /users/<slug>?

To make this work, I think I will store the slug on the UserProfile model, an instance of which will be auto-created whenever either an Author is created or a User signs up. Then the Author instance doesn't need to be created until the admin or the user creates it. If you do select an Author at the time you create an Invitation, then the Author and Invitation will be linked at that time, and the signup will create a User that's linked to the Invitation and transitively to the Author and UserProfile/.

sounds good. seems like this will cover all the relevant scenarios (and works with the new mocked up "Invite" and "Create Author" screens).

so i guess you can go ahead and start on these changes, thanks!

[alexkyllo]

Good to know you've thought through the privacy implications.

Yeah, we can later put a user profile page at /users/<slug>/ that references the same slug field as /authors/<slug>/. I guess /accounts/ paths should be reserved for user account management operations like sign up, sign in, sign out, change password.

I'll start working on this API change in a new branch and notify @onejgordon when it's ready to integrate into staging.

[alexkyllo]

Ok, I think this is done from the backend perspective, in the branch slug_dedupe.

• If an admin invites a user, an Author will be auto-created.
• If an admin invites an existing Author (by including the existing slug value in the nested author JSON when posting to /api/invitations/create--a new UI component will be needed for selecting an existing author to invite by their slug) then when the user accepts the invitation and signs up (with the same e-mail address) their User account will be auto-linked to the Author.
• Added bool field Author.is_activated defaulting to false. It can be set to true via the update author endpoint.
• Removed redundant UserProfile model and moved its fields into Author
• User.username is now always == User.email
• Removed UI field to link new Author to existing User, as every new User will now automatically have an Author
• Note that there are migrations that need to be run to deploy this to staging or prod. python manage.py migrate needs to be run once the code is pushed.

[eplebel]

ok great!

If an admin invites an existing Author (by including the existing slug value in the nested author JSON when posting to /api/invitations/create--a new UI component will be needed for selecting an existing author to invite by their slug)

for now, we can just use a text field for this (as in my mockup above). (though later we could consider using an auto-complete)

Note that there are migrations that need to be run to deploy this to staging or prod. python manage.py migrate needs to be run once the code is pushed.

ok. i assume the existing data in the production DB won't be affected? (even if it does, it wouldn't be that bad, but still better if not).

[alexkyllo]

The migrations don't delete data other than those UserProfile columns that were all either empty or duplicated from Author. So you won't see any data loss.