CMSC 22000 Final report

Quarter: Spring 2025

Feature: Users & Friending

Design and Implementation

User Profiles

An important backend feature is the separation of user and user profile. As users did not have a profile upon sign up (a design choice to allow for API users), one of the first implementations was to ensure profile creation for non-API users. This was done by allowing for profiles to be created when clicking on the ‘My Profile’ page. We then proceeded to expand the ‘My Profile’ page template to display more information including display name, profile photo, bio, and favorite games. Major styling changes were added in CSS and HTML (e.g. cards, texts, and maroon buttons) to make sure the profile UI was user friendly and stayed true to the overall design and look made by the frontend team. The user and user profile models were also tweaked to remove redundancies, such as name fields in both models (we chose to only keep the name in the user model). Certain elements of the user model were defunct and not exposed to the user, such as username. To fix this, we made randomly generated usernames upon signup, and added fields in a ‘My Account’ page accessible from the user’s profile to modify the username, the display name, email, and password.

Friendships and Blocking

Friendship creation through friend invitations was a major feature that was fully implemented through our sprints. Originally, the search bar for searching other users was unintuitive and could only search users by email. We added improvements to the search bar so it was easier to search for users on ChiGame (by name and username rather than the original email search). The search results were also formatted and styled to be displayed in a nice card format rather than the original bare bullet point list. Once users clicked on another user's profile, they were given the option to add them as a friend, which would then send a friend invitation to the other user’s inbox. A major backend detail for making friend invitations work with the inbox (which had the ability to restore deleted notifications) was a design choice to have soft deletes instead of hard deletes. When a friend invitation is accepted or declined, an is_delete attribute is set to true, but the instance remains in the database. New invitations are allowed to be made between two users, as long as no active invitation exists in the database. We also added blocking functionality to allow users to hide their profiles away from other undesirable users. Clicking the block button on a user’s profile page adds them to the blocked list, and that user no longer has access to certain information on your profile. If they try to access your page, they are met with a 404 error. Blocking is also implemented to be reversible, so each user has a ‘Blocked Users’ page accessible through their own profile that allows them to unblock any users they have previously blocked.

Notifications

Throughout the quarter, the notification implementation was significantly expanded and updated. The work done on notifications includes bookmark support, a labelling system including custom labels, and move functionality. Previously, notifications represented a one size fits all model without any user customization. We mainly created new views and added to the notification model, also collaborating with the front end team, in order to make these changes. Users can now toggle a bookmark feature for a notification, in order to keep notifications that are important to them in their own space. We also adjusted the model and views in order to support labelling. The labels that users can choose from are now inbox, spam, social, promotions, and archived. We wanted to mirror a user’s experience on a popular mailing system like gmail, or other popular notification models. As an example, if a user receives a friend request, the notification will show up in the social category.

We also created a custom notification modelling system. We recognized that our pre-set labels may not cover all of what a user may want to label a notification as, so we decided to create a custom labelling system that is somewhat separate from the pre-set labels. Users can type in a label, save it, and then under the pre-set inbox labels they can see their custom labels, and add or remove notifications from this new custom label. Furthermore, in terms of notifications, we found that there were many bugs when it came to the adding and removing friend logic, and we spent most of the first two sprints figuring these issues out. We had to change the delete logic to employ soft deletes, because deleted frid request notifications that did not persist to the database were causing problems within the notification logic. From a high level perspective, as a note to future teams, it is important to be cautious of how the changes you make affect the code base as a whole. Lastly, we finished off our changes to the notification model with the addition of test suites for both notifications and forms. Testing was a good strategy to check the effectiveness and reliability of the notification model.

Groups

The current implementation of the groups component of User Profiles and Friending includes the Group and GroupInvitation models. The Group model has attributes that include name, description, members, created_by, date_Created, and group_admin_permissions. The GroupInvitation model has attributes that include friend_group, sender, receiver, accepted, timestamp, and is_deleted. These two models are utilized in the seven views that include GroupListView, GroupDetailView, GroupCreateView, GroupDeleteView, GroupJoinView, GroupLeaveView, and GroupUpdateView. These seven views have url paths and html templates associated with them that allow the user to utilize them and navigate between them using embedded buttons.

For example, a user could start at the http://127.0.0.1:8000/users/groups/ where they could view a list of all the groups that exist and their details. The user could click a button to create a new group, which would take them to a form where they could input fields like group name, description, and members. Otherwise, the user could elect to click one of the view buttons on the group list page to see more details about the group. In the details screen, the user would see the group name, description, members, creator, and created date. Depending on their membership and login authentication, different buttons would appear on the detail screen. If the user is a part of the group, they will see options to leave the group or update/edit the group. If they choose to edit the group, regular accessing members of the group can alter the people in the group, meanwhile the creator of the group can alter people in the group, name of the group, and description. If the user is not part of the group, they will just see an option to join the group. Both the join or leave buttons will display a confirmation page before executing.

Next Steps

• Update fixtures to have game lists:
  • Currently our fixtures are limited to users with just basic info like name, username and bio. However, we want to also have game lists for each user in the fixtures. When a fixture is loaded, each user should see a preset list of games under their favorites under their profile page. Note: there seems to be a bug where users would already have their favorite game list added, so loading a fixture with a favorites game list results in an error when the view.py function tries to get the favorite game list and finds two for a user.
• Integrating achievements into user profile:
  • One of the stories for achievements mentioned giving users access to their achievements through their profile. This is currently unimplemented. Add consistent CSS styling through user profile functionality: One of the problems that we have not addressed is that the current templates for users do not use a shared set of CSS styles, and instead each template uses its own set of custom styles. We need to make one that is shared across different templates to reduce code duplication and improve consistency.
• Improve User Inbox UI and functionality:
  • Certain features of the user inbox still need to be fixed: e.g. the labeling system right now does not seem to work. The style also needs to be changed to match that of the rest of user profiles (will require effort to create consistent styling).
• Issue #1194: Update users view tests
  • The unit tests for the users app remains very basic and will need to be updated to account for the more complex features that have been added during the past few sprints.
• Issue #1238: Implementing Group Invitation Functionality
  • The group functionality is not fully completed, especially the group invitations. We want to implement it so that a GroupInvitation is made when the group is made. When GroupInvitation is made, a notification needs to be sent to the receiver's inbox that they can respond to similar to friend invitation.