@otobot1 Do you have the Discord user IDs? If not, I don't think there is a way to match the old username+discriminator with their new username. (Discord does still show the last username before the Discord username change, but if the user made a username change in between their last submission and the Discord username change, I don't think we identify them.)

For the update, I guess we'll need to just update the submittedBy field in Rating?
So we just need a page which takes user IDs A and B, and just transfers all ratings by A to B. (only allowing admins).

I don't have the Discord IDs unfortunately. What I have is a list of traditional Discord tags, like otobot1#1564. It's currently in a spreadsheet, but I can put it in a table in the database or a text file on the server. I was wondering if we could use the Originally Known As info that you can see on some people's Discord profiles (see image). This would be the last traditional Discord tag they had before getting their new display name, which would allow us to automatically approve anyone where that old tag matches one in our list. It wouldn't get everyone, but it would get some (hopefully a lot). I haven't looked into Discord's API in quite some time, so I'm not sure if this is doable.

If this winds up being a big pain, we can leave it for a v0.2.1 update.

For the update, I guess we'll need to just update the submittedBy field in Rating?
So we just need a page which takes user IDs A and B, and just transfers all ratings by A to B. (only allowing admins).

Yep

I don't have the Discord IDs unfortunately. What I have is a list of traditional Discord tags, like otobot1#1564. It's currently in a spreadsheet, but I can put it in a table in the database or a text file on the server. I was wondering if we could use the Originally Known As info that you can see on some people's Discord profiles (see image). This would be the last traditional Discord tag they had before getting their new display name, which would allow us to automatically approve anyone where that old tag matches one in our list. It wouldn't get everyone, but it would get some (hopefully a lot). I haven't looked into Discord's API in quite some time, so I'm not sure if this is doable.

If this winds up being a big pain, we can leave it for a v0.2.1 update.

How does the site work right now if those users aren't in the database? Ratings need a user (not null) according the prisma schema.

I was setting up Discord sign in and got a Prisma error - the model User doesn't have email & emailVerified fields. Should I add those, or do you not want to store that data?

I don't have the Discord IDs unfortunately. What I have is a list of traditional Discord tags, like otobot1#1564. It's currently in a spreadsheet, but I can put it in a table in the database or a text file on the server. I was wondering if we could use the Originally Known As info that you can see on some people's Discord profiles (see image). This would be the last traditional Discord tag they had before getting their new display name, which would allow us to automatically approve anyone where that old tag matches one in our list. It wouldn't get everyone, but it would get some (hopefully a lot). I haven't looked into Discord's API in quite some time, so I'm not sure if this is doable.
If this winds up being a big pain, we can leave it for a v0.2.1 update.

How does the site work right now if those users aren't in the database? Ratings need a user (not null) according the prisma schema.

The users are currently in the database in the User table, but once v0.2.0 goes live new people will be able to create users. So, we would need to store the list of "legacy users" in a new table or a text file or something to support any automatic linking of new and legacy users.

I was setting up Discord sign in and got a Prisma error - the model User doesn't have email & emailVerified fields. Should I add those, or do you not want to store that data?

I'd rather not store it, as we don't need it for our purposes. It's been nearly a year since I looked at the Auth stuff, but I did create a custom Prisma Adapter and Discord Provider that should take care of that error. I'm pretty sure I got it all working. If you're writing server-side code, import the session using the getServerAuthSession wrapper function. If you're writing client-side code, call useSession and the SessionProvider in /pages/_app.tsx will provide a session if the user is logged in, or null if not. Either way, the session object you get is defined in the session callback in the authOptions object.

So I had a bit more of a thought about how to handle unlinked legacy users, and I also noticed that the accountStatus column in the User table has a possible value of Unlinked. My idea:

• Unlinked users are only tracked by their accountStatus.
• Logged in users are able to claim any unlinked user.
  • All users see a blurb on the home page telling them that, if they submitted ratings via the google forms, they can claim their old user.
    • When the user clicks the link in the blurb, they go to the claim-user page.
  • The claim-user page lets the user search through all unlinked users and claim one.
    • When the claim is submitted, an entry is created in a new UserClaim database table.
      • Each row in the table should link to the requesting user and the claimed user.
      • As a single user may claim or be claimed by multiple users, also have a numerical autoincrementing id column
    • After calling the API and creating the claim entry in the database, the claim-user page updates to show:
      • Their claim has been submitted successfully.
      • They need to contact one of the verifiers on Discord to verify their claim.
        • Include the same permanent link to the Discord that is in the website footer.
        • Direct them to post a screenshot of their claim in the #claim-user channel (I will create this when I have a chance).
      • The claim id.
      • The claimed user's id, discordUsername, and discordDiscriminator.
        • This can be a followup issue, but we should change the User table ids to be autoincrementing numbers instead of UUIDs so that they are more human-readable.
          • This will require changes to the db-import repo, and a re-import of the old data to the production db.
          • I believe NextAuth requires the User id to be a string, but we should be able to enforce it being a numerical string by removing the default value from the Prisma schema and always providing a default value ourselves in the Prisma adapter.
• Logged in users with the Admin or Super_Admin permission are able to access a claim verification page.
  • Ideally this page will show all claims by default and allow searching by claim id.
  • When the claim is verified:
    • All foreign keys in the database pointing to the claimed user are changed to point to the requesting user.
    • A info level log entry is printed to file using the serverLogger specifying:
      • The requesting user's id.
      • The claimed user's id, discordUsername, and discordDiscriminator.
      • The verifying user's id.
      • The list of foreign keys updated.
    • Finally, the claim and claimed user are deleted from the database.

Please let me know if you have any questions/comments on this!