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.
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).
