PR 5: Mute, Block, and Report Model

[aviendha-andrus]

Mute, Block, and Report Model

Add Mute, Block, and Report User API Endpoints to Chat System

---

Overview

What does this PR do?

This PR adds authenticated API endpoints that allow users to mute, block, and report other users within the chat system. Each action is backed by database models and includes validation to prevent self-targeting or duplicate records.

---

Key Features & Changes

What has been added or changed?

✔ Core Feature Implementation: Users can mute, block, and report others via RESTful POST endpoints
✔ Validation Improvements: Prevents self-muting/blocking/reporting and duplicate entries
✔ Custom GET logic: Users can fetch a list of users they’ve muted/blocked/reported
✔ Serializer Enhancements: Serializers now return readable usernames with IDs
✔ New ViewSets & URLs: ViewSets added with router-based routing

Example:

• Added MuteViewSet, BlockViewSet, ReportViewSet
• Implemented create() and list() methods with custom logic and validation
• Added serializers with username field for clarity
• Registered routes using DefaultRouter in chat/urls.py

---

Why This Is Needed

What problem does this solve?

This feature empowers users to moderate their chat experience by muting or blocking disruptive users, and reporting inappropriate behavior for admin review. It lays the foundation for better user safety and content control.

---

Related Issue

🔗 This PR closes Issue #101

---

Implementation Details

How was this feature developed?

• Built using DRF ViewSets and ModelSerializers
• Added validation inside create() methods using serializers.ValidationError
• Introduced model-level clean() and full_clean() to prevent self-moderation
• Custom list() methods used for filtering data by user

---

Design Documentation (If Applicable)

Diagrams & Visuals

• UML diagram:

---

How to Test This PR

Step-by-step testing guide

1️⃣ Model accuracy and logic

• Shell

  python manage.py shell

• Admin panel

  python manage.py createsuperuser

  python manage.py runserver

Test that a person can’t mute/block themselves, and that you can't mute or block the same person twice.

With either the shell or the admin panel, create 2/3 test users with profiles and passwords. Choose one of the users to "Login" as and have them block the other 1/2 people.

2️⃣ Creating an authentication token for a profile
fill in the name and password portions of the following code

curl -X POST http://localhost:8000/api/token/ \ -H "Content-Type: application/json" \ -d '{"username": "<name>", "password": "<password>"}'

3️⃣ POST requests

curl -X POST -H "Authorization: Bearer <access code>" -H "Content-Type: application/json" -d '{"muted_user": <pk of who to mute>}' http://127.0.0.1:8000/chat/mute/

4️⃣ GET requests
Iterate through mute, block, and report testing that the GET request lists all the people the "Logged in" person has blocked

curl -X GET -H "Authorization: Bearer <access code>" http://127.0.0.1:8000/chat/mute/

---

Files Added/Modified

📂 List of important files changed in this PR

File Name	Description
chat/views.py	ViewSets for mute, block, report
chat/serializers.py	Serializers with username annotations
chat/urls.py	API routing for moderation endpoints
users/models.py	Profile model
users/managers.py	Profile model (referenced for logic)
users/admin.py	Readability on the Admin Panel
users/consumers.py	Prevents blocked users from sending messages.

---

AI Code Usage

🤖 Was AI-generated code used in this PR?

• Yes (Used to structure serializer logic)

  https://chatgpt.com/share/680f8739-ba48-800c-86b2-0f6d64889d81

• No (All code was manually implemented.)

---

Checklist for Reviewers

Things to check before approving this PR:

• Are blocked/muted/reported records returned correctly?
• Is self-blocking/muting/reporting prevented?
• Are all endpoints authenticated-only?
• Are duplicate records blocked by unique constraint and logic?
• Does each ViewSet return readable user data (e.g., usernames)?

---

Next Steps & Future Enhancements

What improvements can be made after merging?

• Add "unblock"/"unmute" DELETE endpoints
• Should I change report to only one for each person? I was thinking that it might be a good idea for someone to be able to make multiple reports. I also held off on not allowing people to make reports of themselves. I feel as if someone felt the need to report themselves it might be a good idea to leave that avenue open. Let me know what you think!

---

Final Notes

Thank you for reviewing! Let me know if you'd want help debugging :3

[omgdory]

🔍 Peer Review

---

✅ What Looks Great

• The endpoints work precisely as intended.
• Information is stored appropriately.
• Requests need the appropriate authentication level.
• The steps to testing the PR are really easy to follow.
• Code is clean and modular while following separation of responsibility between managers and models. Corresponding serializers and views also look good.

---

💡 Suggestions for Improvement (if any)

• Adding testing would prove beneficial and help us stick to test-driven development practices.
• Unblock/unmute DELETE endpoints.
• As mentioned in the body of your PR, these can be done in a future PR!

---

🧪 Tested This Feature

As described in the the PR. Rather than using the curl command, I used Postman Desktop to more easily format my requests. There shouldn't be any difference in these approaches other than a superfluous header in my requests.
Checklist:

• Are blocked/muted/reported records returned correctly?
• Is self-blocking/muting/reporting prevented?
• Are all endpoints authenticated-only?
• Are duplicate records blocked by unique constraint and logic?
• Does each ViewSet return readable user data (e.g., usernames)?

---

🔄 Next Steps

• Implement the aforementioned DELETE requests.
• Create tests to follow test-driven development practices.
• Continue to the next features.

---

🚀 Final Thoughts

Great work, really well-done and well-documented! 🚀

[codecov]

Codecov Report

Attention: Patch coverage is 73.33333% with 4 lines in your changes missing coverage. Please review.

Project coverage is 80.98%. Comparing base (fa41293) to head (569d4b1).
Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
backend/apps/chat/consumers.py	73.33%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #179      +/-   ##
==========================================
- Coverage   81.16%   80.98%   -0.18%     
==========================================
  Files          17       17              
  Lines         775      789      +14     
  Branches       51       55       +4     
==========================================
+ Hits          629      639      +10     
- Misses        123      125       +2     
- Partials       23       25       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashley-arellano]

🔍 Peer Review: Great Job on This PR!

Hey Aviendha 👋 — just finished reviewing your PR titled "PR 5: Mute, Block, and Report Model". Here’s my feedback:

---

✅ What Looks Great

• The models created in this PR fully satisfy the requirements listed in Issue #101 and includes extra, useful methods such clean() to ensure users can't mute or block themselves.
• Additionally, the HTTP requests and their endpoints created in this PR satisfy the previous mentioned issue. They perform POST for either blocking, muting or reporting user and creates the intended objects. I verified this by via CURL (by passing a JTW token).
• Backend implementation for blocked/muted user works as intended when testing via existing Chat feature
  • (Albeit a small visual bug occurs with typing indicator hanging but this is due to existing frontend code not accounting for blocked/muted users yet. Something to consider for a future PR.)

---

💡 Suggestions for Improvement (if any)

These are ideas for future improvements or things to address before merging.

• Consider refactoring new code in consumers.py to make it more readable.
• As mentioned in your PR, adding DELETE requests so user can undo mute and block.
• Though, muted/blocked user not able to send their message. The user who blocked them is still able to. This is something that can be fixed down the line however.

---

🧪 Tested This Feature

I ran the following test steps:

• ✅ Tested the POST requests via CURL
• ✅ Ran the existing chat feature (by running both frontend and backend servers) and ensure that the user who is blocked/muted is not able to send a message to the other user.
• ✅ Looked over modified/new code.

Everything behaved as expected 🎉

---

🔄 Next Steps

• Add unit testing for consumers.py to appease codecov

---

🚀 Final Thoughts

Great job with this PR! This helps fleshes out our existing chat feature and makes progress towards our project. Therefore, I will approve this PR : D

[omgdory]

Adding the serializers was a good call. Nothing seems to have broken since the initial review. Everything looks good! 💯