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.
Previously, DSN would not be able to parse special characters like "@"
or "/". This adds support by requiring the input to be url encoded and
then DSN would decode it after parsing.
A user will have an accessedAt timestamp that will update at most once
per day if they make some API call. This timestamp can then be used
find active users and calculate daily, weekly, and monthly active users.
To ensure consistent updates to the user the $user from the resource
is always updated to the user making the request, including requests
like Create Account, Update Team Membership Status, and Create Phone
Session (confirmation). This ensures the shutdown can update the
accessedAt timestamp if there was a $user set.
