[bug] Cant post update in Research Module

[davehakkens]

Describe the bug Two (out of three) users reported they can't upload an update to a research on Project Kamp. It's gives the message beta-tester role required to access this page We tried refreshing and using another browser.

Expected behaviour all three users have a beta-tester role. marionagimenez can post updates kevincheung and kaegh can not.

Screenshots

Additional context All three are added as a contributor to an existing research topic

[thisislawatts]

Interesting 🤔 I am seeing a similar bug in an e2e test.

Somewhat related, do we think that Research should still only be for beta-users?

[iSCJT]

Something cache related?

[thisislawatts]

@davehakkens Can you include which Research article this was?

[davehakkens]

this one for kaegh: https://community.projectkamp.com/research/making-a-sturdy-single-person-tent this one for kevincheung https://community.projectkamp.com/research/can-we-turn-invasive-trees-mimosa-into-something-useful

Somewhat related, do we think that Research should still only be for beta-users?

Dont think we are ready yet to release public on Project Kamp. The mission + moderation is not yet in place. Would be more ready for Precious Plastic though

[thisislawatts]

Interesting both of these humans have 2 entries in the v3_users table associated with their usernames.

I will need to root around in the code bit more to understand the why here. But I believe that there is a manual intervention I can make that will fix this.

Note the creation dates on kaegh 2 user objects:

• 2023-04-03T17:18:47.891Z
• 2023-04-03T17:18:47.891Z

[davehakkens]

Thanks for digging. This double entries for certain usernames gets a bit messy.. I thought it was a thing from the past, but still seems to happen with newer accounts as well. I'd be up for manual intervention for now!

[thisislawatts]

Any idea how these accounts were created? I attempted to recreate the issue by going via the Join use flow and ended up with a single entry in v3_users each time.

[thisislawatts]

In the meantime I have removed the user accounts, so the ones remaining have the userName as the _id

[davehakkens]

Any idea how these accounts were created? I attempted to recreate the issue by going via the Join use flow and ended up with a single entry in v3_users each time.

Not sure.. But this also reflects in the admin panel. Maybe a duplicate for everyone that gets a beta-tester role?

I think @chrismclarke knows more about this.

[thisislawatts]

I would welcome a second set of eyes here, but this looks to be the bug to me. We're writing User documents using the ._authID property rather than the _id property. https://github.com/search?q=repo%3AONEARMY%2Fcommunity-platform%20doc(updatedUser._authID)&type=code

Hypothesis: Notifications result in a new duplicate User document being created that has the _authID rather than the userName attribute for the document ID.

This is being compounded by this code which ties an auth user session to a User document. When there are duplicate profiles available the function will resolve to lookup2.

// TODO
// this is a bit messy due to legacy users having mismatched firebase data and ids
// should resolve all users so that a single lookup is successful
// to fix a script should be run to update all firebase_auth display names to correct format
// which could then be used as a single lookup
public async getUserProfile(_authID: string) {
  const lookup = await this.db
    .collection<IUserPP>(COLLECTION_NAME)
    .getWhere('_authID', '==', _authID)
  if (lookup.length === 1) {
    return lookup[0]
  }
  const lookup2 = await this.db
    .collection<IUserPP>(COLLECTION_NAME)
    .getWhere('_id', '==', _authID)
  return lookup2[0]
}

[iSCJT]

Duplicate user issues have been addressed through various pr's and manual data fixes.