Right now, all users on a team are equal in terms of permissions. Eventually, we could implement functionality for one user to be a leader, and give them permission to remove other users from the team, and transfer leadership, etc. Should this even be an option? This issue is to keep the idea as a possibility for the future.

Update API Docs and README to reflect changes from feature/rewrite. Also update the diagrams directory with new DB schemas.

We have a lot of small changes that need to take place in the code, identified with TODOs. Also, we want to handle any issues with the existing code (general bugs or things that we believe should be refactored).

Work towards updating and improving team matching algorithm.

Currently in progress: #50

Overall: main feature - matching system for participants
—————————
Flow

Completely new user: Sign up —> Log in —> Fill out profile
User with no profile: Log in —> Fill out profile
User with profile: Log in —> Dashboard
—————————
Dashboard

links to the different features

-“my matches” button
-option to see more teams (discover/explore page)
-messages?
-link to your profile
—————————
Endpoints

-Login (take user input from frontend, verify with database)
-Sign up (take user input from frontend, make sure user doesn’t exist, enter into database)
-Profile (pull up user info from database)
-My matches: pull from database
-Discover page: show teams that haven’t been seen/matched with yet
-Messages: not sure how to implement this quite yet. Might now need it, just depend on given communication channels

Right now, all of our endpoints call functions, and parsing input takes place inside the functions themselves. We want to separate the endpoint logic from the actual "action" logic, so everything related to the Flask request (method type, processing the request body) should be in src/flaskapp/api.py, and everything relating to the actual function should be in its respective file. This was partially resolved by #6, but still needs to be done for the rest of the files.

Currently, many files use the format_string(s) method from src/flaskapp/util.py to handle input in the form of a string of multiple items, separated by commas. Ideally, instead of accepting a string and converting it to a list for our use, we should require consumers of our API to pass in information as a list directly.

The other key logic that the format_string(s) method handles is removing leading/trailing spaces and converting strings to lowercase, which it should do. There are many other places in the code that also do the same thing, but do not currently use the format_string(s) method.

Action Required:

• Convert this method to handle the following tasks:
  1. If the input is a str, all leading/trailing spaces and converting characters to lowercase
  2. If the input is a list, follow the same action as step i for each item in the list
  3. If the input is not a str, convert it to a str and then follow the same action as step i
• Add the format_string() method anywhere it can be used (with the new functionality for both strings and lists, it can now be used in places like this snippet from src/flaskapp/api.py.

EXISTING:

data = request.get_json(silent=True)
email = data["user_email"]
email = email.strip().lower()

NEW:

data = request.get_json(silent=True)
email = format_string(data["user_email"])

By making this change, we will not be breaking any existing code that calls format_string. It just needs to be updated in the comments and documentation that input must come in directly as a list, and not as a str of comma separated values.

Transition away from storing our own users, and work towards integrating user profile objects from LCS (Backend Core).

We should create a new collection (let's say archive) where we would store team1 ( the variable of the team in team_confirm.py).

Add team_id to the user document so that we can know what team a user in my fetching his user profile.

Add pagination to the GET /teams endpoint to allow for partial retrieval of open teams.

Fix CORS issue from HackRU/frontend#362 (comment)

Seems like CORS is still acting up, converting this to an issue so that we can track this much better

Write unit tests for each function, and ensure that all cases are covered. In addition, integrate TravisCI with the repository to run all tests on PRs.

We want to add comments to every function to understand its purpose. This will make it easier for future developers!

Currently, TeamRU only supports reading a user's own profile. We should set up another endpoint to allow anyone (with a valid token) to access another TeamRU user's profile, given the other user's user_id (email).

Sample structure:
GET /users/[email protected]

In the long term, we want to make sure that code is properly styled and commented to make it easier for developers to maintain and enhance.

Styling

To achieve this on our current codebase, we will use a combination of pylint and black.

pylint

• Useful for identifying issues such as import order, naming conventions, missing docstrings, etc.
• Doesn't actually make any changes, but provides a list of suggestions that can be made to improve the code
• All pylint codes can be found here

black

• Aggressive but useful for creating standardized code styling
• Automatically fixes issues such as files ending without newlines, single quotes instead of double quotes, trailing whitespace, etc.

In these instances where we feel like ignoring pylint warnings, or where pylint and black disagree, we will suppress pylint. These issues will be handled on a case-by-case basis.

Comments/Documentation

In general, Google's Python Style Guide is a great resource. Specifically, we will be using their guidelines on comments and docstrings to document our code. Again, this isn't set in stone - any disagreement with the styling conventions can be handled on a case-by-case basis.

Workflow

In general, the developer workflow should look a little like this:

write code
run black
run pylint
while pylint raises warnings:
    for warning in warnings:
        if warning is important:
            fix it
        else:
            suppress it
    run pylint
run black
push code

I think we can specify to mongodb to not return the meta part.

Search for projection operators for Mongodb. I am also new to this as well.

Originally posted by @JasonCheng1 in #7 (comment)

I'm not too worried about read speed considering we don't expect to be handling massive amounts of data, but definitely a good improvement that we can look into.

We want to make sure that the field names in POST requests match the field names returned in GET requests for teams and users, specifically in regards to the id fields.

PyGithub provides GitHub API access in python such that we can find all repository from a user. finding out what skills they are comfortable with.

TeamRU currently converts all fields to lowercase, including team name and description (which probably should not be modified). We should update to allow users to stylize their team name and description however they want, and just trim whitespace at the ends.

Currently, input validation (making sure requests have all the required fields) takes place across different methods, and is not standardized. We can create JSON schemas for each endpoint and validate against them to ensure that every request comes with all of the required information.

Problem
Currently, teams cannot change their team name because of the way our database is structured. We use team names as the _id field for objects in the teams collection.

Potential solution
Modify the workflow so that upon team creation, we generate a random string that is used for the _id field, and store a separate name field with a team object.

Things to keep in mind

• Make sure random id generated does not already exist in the teams collection
• When teams want to change their name, make sure it does not conflict with another team's name (do we need this?)

One thing to note while I was designing the Unify methods I overlooked the relationship where we may want to simulate a team that is interested to join another team. What we currently have is the relationship where a team is asking another team to join theirs. I think what we have here allows us to do what we want but it may feel weird for our end users. Food for thought.

Originally posted by @JasonCheng1 in #7 (comment)

In order to implement this we may need to restructure how we store invites in the db (we already have outgoing_inv and incoming_inv, maybe an additional list for interests?) as well as the interaction workflow (right now, we have invite/rescind and confirm/reject, where one team takes care of both parts - if we want interest requests to be made by team1 and merge to be made by team2, it will have to work a little differently).