Helping imported users claim their posts


(Hélène Martin) #1

The experimental mbox importer (which works really well!) imports all users as staged users. This means that community members need to create new accounts and get no feedback about whether or not the email address they use for Discourse matches the email address in the import. Until the functionality to merge users is added, this is potentially problematic. We don’t want users creating accounts with email addresses other than the one they used on the old forum.

Ideally, we could instruct users to use the reset password functionality and turn off new user creation for a few days while people migrate over.

To get the desired behavior, we could unstage all users but I think they would then get digests and mentions and would need to create an account to stop them. Am I understanding that correctly? Would making the users not staged AND inactive give us what we’re looking for?

At a higher level, this could maybe be a use case for enabling password reset for staged users. Conceptually, it makes sense that the users would be imported as staged but it would also be great if they could get some help using the email address that lets them claim their old posts.


(Felix Freiberger) #2

This should make sure that users can “sign up” by trying to log in / resetting their password. However, this is a bit of an unusual configuration, so I’d assume there are a few edge cases hiding here. Personally, I ran into these users not being able to email in, but I’m sure there’s more…


(Andrew Waugh) #3

Doesn’t setting them to inactive mean that they will be purged according to “purge unactivated users grace period days”

We have a large number of “dormant” accounts, post import. We don’t want them purged (and we don’t want email summaries going out to them), we’d like to leave them “on deck”, but dormant.

We could eliminate some of these “dormant” accounts if there were a “merge users” facility, but we’d still be left with the accounts and posts of users who are in many cases no longer with us.


(Felix Freiberger) #4

This setting only affects users that have never been activated (they don’t hold a “full” account yet) :slight_smile:


(Andrew Waugh) #5

Cross your heart and hope to die? Promise that the way this status is used never changes?


(Felix Freiberger) #6

Risk is what makes life interesting :stuck_out_tongue:

No, seriously: I have been running a site with previously active and now inactive users for two years now, and users with posts have never been purged.

This is intentional behavior:


(Hélène Martin) #7

Thanks a lot for the ideas and warnings, everybody! After reading your comments, @yanokwa and I got nervous about all the things we don’t understand regarding inactive users and decided to just unstage everybody with User.update_all(staged:false) and leave them active.

That seems to have worked well – community members are successfully claiming their accounts and not creating duplicates. I now see that those who haven’t logged in yet and posted to the old list within the last 365 days got a digest. I think that happened to just include our “introduce yourself” post so it seems to have worked out really well. Will update here if anything else interesting happens.


(Andrew Waugh) #8

Avoid users creating “split head” accounts. Moving a couple of posts over to a users “real” account, and getting them to use that is no big deal, but without a user merge it becomes really tedious to move more than about 10-15 posts.

You’re fortunate if you haven’t got many accounts with emails that no longer exist. If I turn email summaries on we will get blacklisted by various ISPs pretty quickly (about 40K accounts, about 1000 of them are active on the new platform).


(Sam Saffron) #9

I think it is kind of inescapable that we need support for user merge for big mailing list imports, I have seen quite a few cases in old mbox imports where users switch emails a few years in.

I think merge is the most robust way of solving this, but we are going to need a few features first to unlock this, more than one email per account is a big one.

Agree that streamlining on-boarding is good, but account merge is the thing you really really need.


(Hélène Martin) #10

@JagWaugh That’s a really good point about potentially getting blacklisted. The default for digests is that they’re sent to users who have been active within the last 365 days (in this case, that means they have posted to the original list within the last year). I don’t think we had any dead email addresses used within that time period. We also gave about 3 weeks of notice that the list was moving so (hopefully) the digest wasn’t too surprising. One thing we thought about is reducing that activity threshold so, for example, only people active in the last month got the digest. That might be a solution for a community in which members change email addresses often.

@sam I agree with you that merge is important but I can also appreciate that it’s a daunting technical task! In the mean time, I do think allowing password recovery for staged users would be a simple, helpful addition that would continue to be useful once merge is added. I’ll post on that feature thread!


(Andrew Waugh) #11

@lognaturel,

The way our import worked, every single account had “Last Seen” to the day the import ran.

All 37000 of them.

If you haven’t already gone live, look really carefully at all your defaults. If you have, for example, a “help” or an "Announcement’s category that you want everyone to be watching by default, then set that in settings AND set it for all the accounts you’ve imported (or verify that they are set correctly).


(Hélène Martin) #12

@JagWaugh Ooh, that’s a problem! :scream: Good thing you noticed that before flipping the switch. The experimental mbox importer does a really nice job with setting the expected dates from the emails sent so luckily we didn’t have that kind of problem.

Thanks for the tip about the category watches! It does look like imported accounts aren’t watching the defaults, probably because we didn’t think to set them before the import. Oops.