The user token from the URL is generated with the secret composed of server secret, user password, and user's "createdAt" timestamp (source). When the token is issued, the secret does not contain all of the above elements since the user instance was loaded without the password as per the default model scope. On the other hand, when the token is being checked, not the same secret is used because of fetching the "unscoped" user, i.e. user instance containing the password hash (source).
To ensure the same secret is used for both issuing and verifying the token, it's needed to load the "unscoped" user instance for creating the invitation email.
Fixes #964
The user token from the URL is generated with the secret composed of server secret, user password, and user's "createdAt" timestamp (source). When the token is issued, the secret does not contain all of the above elements since the user instance was loaded without the password as per the default model scope. On the other hand, when the token is being checked, not the same secret is used because of fetching the "unscoped" user, i.e. user instance containing the password hash (source).
To ensure the same secret is used for both issuing and verifying the token, it's needed to load the "unscoped" user instance for creating the invitation email.