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.
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.
Update the OAuth2 class to throw an exception if an API call to the
OAuth2 provider fails and update the endpoint to redirect to the
failure url with the information from the OAuth2 provider.
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.
