Users Collection ID Field

[jpgrusling]

I'm trying to add this plugin to an existing project with existing admin users. The project uses MongoDB for the storage. User IDs in the database are persisted as ObjectIds. When using this plugin while enabling the built in Payload auth, I am unable to log in. I get a successful response from the login endpoint and a cookie. However I remain at the login screen. Upon further investigation, it appears related to the fact that the ID field of the users collection is an ObjectId instead of a string. I am able to log in if I change the data for in the database. I am curious if there is a reason why you chose to explicitly define the ID field. I would be glad to review the code and submit a PR if this choice wasn't made deliberately. However if this was an intentional choice that you'd like to keep then there's no reason for me to investigate.

[CrawlerCode]

Hey,

Auth.js generates the user ID with crypto.randomUUID() (see here) and passes it to the adapter to create the user in the database. For this reason, I have created a custom ID field that corresponds to the schema.

---

I tried a bit and if I remove my custom ID field, Payload will ignore the provided ID from Auth.js and generate an ObjectId. But I think this is a bit strange behavior if the ID is "randomly" changed during the registration process.

DEBUG (payload-authjs (PayloadAdapter)): Getting user by account '41094392' of provider 'github'
    provider: "github"
    providerAccountId: "41094392"
DEBUG (payload-authjs (PayloadAdapter)): Creating user '69418c50-5248-4f21-9796-831e1d94e033'
    userId: "69418c50-5248-4f21-9796-831e1d94e033"
    user: {
      "id": "69418c50-5248-4f21-9796-831e1d94e033",
      "name": "CrawlerCode",
      ...
    }
DEBUG (payload-authjs (PayloadAdapter)): Linking account for user '688e18c36cc2231ed0456632'
    userId: "688e18c36cc2231ed0456632"
    account: {
      "providerAccountId": "41094392",
      "provider": "github",
      "type": "oauth",
      "userId": "688e18c36cc2231ed0456632",
      ...
    }

[jpgrusling]

I'm wondering if instead of hijacking the native Payload ID field, a better solution would be to track the Auth.js ID value as a separate field in the collection. That way it wouldn't interfere with the existing data so the migration story would be better. Additionally, it would resolve the issue you cite above where the ID could change if the user switches from native Payload login to Auth.js login.