The CREATE TEAM MEMBERSHIP endpoint requires the email of the user to be added to the team. If the user does not exist in the project, a new user is created with the specified email and added to the team.
The first version of the test creates 5 users, and then adds them to the newly created team. This process is more streamlined now, by using the CREATE TEAM MEMBERSHIPS behaviour to create a user on the go and create a membership for them immediately after.
I also change the way I add user IDs to the array, by using the shorthand notation instead of the `array_push` function.
This commit contains changes in 3 places.
- First I changed the placement of an informative comment in the DELETE TEAM controller, and moved it outside of the loop. I did this when Steven pointed out that the behaviour I describe in the comment is for the whole loop.
- The second change is the removal of my first test. I was facing quite a few issues with creating users in the test, and ended up using the CREATE TEAM MEMBERSHIP to perform 2 actions at once -> create a new user if one doesn't exist with the provided email, and create a membership for the user. Before this approach, I had quite a bit of code that didn't work, and it seems like I removed some things that weren't supposed to be removed, and didn't change variable names where necessary. Anyway, I figured that the problem has something to do with the user being created on the client side, so I moved the test to the server side.
- The new test I implemented does the same thing as my previous failed test, but in more detailed and distinct steps. The test first creates 5 new users inside of a loop, and pushes each new user's ID to an array called 'new_users' if the response is as expected. Then a new team is created. The next step is to create memberships for all 5 users. If all these steps pass, the new team that was just created, is deleted, and we check to make sure the new users have 0 team memberships each.
Formatter and linter showed no errors. Tests were successful on localhost.
Until we have a clearer picture of why we need it, it would be best to
remove it since it's easier to add it later than to remove it after it's
released.
Setting a password can cause problems with other APIs that expect the
password to be null. In addition, it doesn't match the implementation
for the other APIs that create a user without a password (Create Magic
URL Session, Create Phone Session, Create Anonymous Session, etc).
This allows us to retain the OAuth2 info even if the session is
deleted. This also provides a foundation for allowing multiple emails,
phone numbers, etc, not from an OAuth2 provider.