For invites use scope "*:project-invites" instead of "*:project-members"

[maxceem]

Follow up from #483.

At the moment for invites we use the same M2M scopes as for members #483 (comment). But as per #483 we should have a separate scope for them:

• all:project-invites
• write:project-invites
• read:project-invites

[maxceem]

@vikasrohit as we would have separate scope for invites, should we also stop returning them in GET /projects endpoints if M2M token doesn't have read:project-invites scope? The same as we want to do for members #560 for consistency?

[vikasrohit]

Yes please.

[maxceem]

Sum up:

• use separate scope for invites as per For invites use scope "*:project-invites" instead of "*:project-members" #561 (comment)

• when we are returning invites in GET /projects or GET /projects/{id} endpoints we have to filter them:

  • if user has permission READ_PROJECT_INVITE_NOT_OWN then we can return in the list of all invites
  • else if user has permission READ_PROJECT_INVITE_OWN then we can return in the list only own invite (i. e. invite which has userId or email equal to the req.authUser)
  • else: user doesn't have any of the above permissions, so user gets empty list of invites

  create at least 1 unit test in each endpoint to check if M2M scope doesn't have read:project-invites then such a user wouldn't get any invites with project

  We already have this logic in the endpoint GET /projects/{id}/invites.