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.
It's important to use userInternalId so that if a user is recreated
with the same ID, lookups for the user will not return the data
of the old deleted user.
We will still store userId in data so that it can be pulled out and
returned for the log API calls.
Version 1.1.0 was an incorrectly named git tag; it was equivalent to
0.2.0. This bump to 0.3.* is safe because it adds Registrar,
but it won't be used in Appwrite yet. Bumping to 0.3.* is necessary to
fix some bugs where valid domains were considered invalid.
