feat: add teamId filter to task retrieval and update related logic #168
Conversation
- Introduced a new query parameter `teamId` to filter tasks assigned to a specific team. - Updated the `TaskRepository` methods to support filtering by `teamId` in both task listing and counting. - Enhanced the `GetTaskQueryParamsSerializer` to include `teamId` as an optional field. - Modified the `TaskService` and `TaskListView` to handle the new `teamId` parameter in task retrieval requests. - Updated OpenAPI documentation to reflect the new filtering capability for tasks.
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Summary by CodeRabbit
WalkthroughA new optional query parameter, Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant TaskListView
participant GetTaskQueryParamsSerializer
participant TaskService
participant TaskRepository
Client->>TaskListView: GET /v1/tasks?teamId=TEAM123
TaskListView->>GetTaskQueryParamsSerializer: Validate query params (teamId)
TaskListView->>TaskService: get_tasks(..., team_id=TEAM123)
TaskService->>TaskRepository: list(..., team_id=TEAM123)
TaskRepository-->>TaskService: Filtered tasks by team
TaskService-->>TaskListView: Filtered tasks
TaskListView-->>Client: Response with filtered tasks
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
- Reformatted the `list` method signature in `TaskRepository` for better readability by breaking it into multiple lines. - Ensured consistent spacing and organization of import statements within the method.
- Modified assertions in the `TaskSortingIntegrationTest` to include a `None` parameter in the `mock_list` calls for various sorting scenarios. - Ensured consistency in the test cases by aligning the method calls with the updated signature of the `list` method in `TaskRepository`.
![korbit-ai[bot]](https://avatars.githubusercontent.com/in/322216?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review by Korbit AI
Korbit automatically attempts to detect when you fix issues in new commits.
| Category | Issue | Status |
|---|---|---|
 |
Incomplete Team Task Filtering ▹ view | |
 |
Duplicate Team Task Filtering Logic ▹ view |
Files scanned
| File Path | Reviewed |
|---|---|
| todo/serializers/get_tasks_serializer.py | ✅ |
| todo/repositories/task_repository.py | ✅ |
| todo/views/task.py | ✅ |
| todo/services/task_service.py | ✅ |
Explore our documentation to understand the languages and file types we support and the files we ignore.
Check out our docs on how you can make Korbit work best for you and your team.
| team_task_ids = [assignment.task_id for assignment in team_assignments] | ||
| query_filter = {"_id": {"$in": team_task_ids}} |
There was a problem hiding this comment.
Incomplete Team Task Filtering 
Tell me more
What is the issue?
The team filter doesn't consider tasks created by team members, only tasks assigned to the team.
Why this matters
Team members won't see tasks that were created by their teammates but not explicitly assigned to the team, potentially missing important team-related tasks.
Suggested change ∙ Feature Preview
Modify the team filtering logic to include tasks created by team members:
from todo.repositories.team_repository import UserTeamDetailsRepository
# Get team members
team_members = UserTeamDetailsRepository.get_by_team_id(team_id)
team_member_ids = [str(member.user_id) for member in team_members]
query_filter = {"$or": [
{"_id": {"$in": team_task_ids}},
{"createdBy": {"$in": team_member_ids}}
]}Provide feedback to improve future suggestions
💬 Looking for more details? Reply to this comment to chat with Korbit.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (6)
schema.yaml(1 hunks)todo/repositories/task_repository.py(2 hunks)todo/serializers/get_tasks_serializer.py(1 hunks)todo/services/task_service.py(1 hunks)todo/tests/integration/test_task_sorting_integration.py(6 hunks)todo/views/task.py(2 hunks)
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: Achintya-Chatterjee
PR: Real-Dev-Squad/todo-backend#52
File: todo/views/task.py:106-106
Timestamp: 2025-05-29T21:36:27.694Z
Learning: Issue #26 in the Real-Dev-Squad/todo-backend repository comprehensively tracks user authentication implementation including registration, login, JWT tokens, and making task APIs require authentication. This covers replacing hardcoded user ID placeholders like "system_patch_user" with actual user ID extraction from authenticated requests.
Learnt from: Achintya-Chatterjee
PR: Real-Dev-Squad/todo-backend#52
File: todo/views/task.py:106-106
Timestamp: 2025-05-29T21:36:27.694Z
Learning: Issue #26 tracks the implementation of user authentication in the todo-backend project, which includes extracting user ID from request context to replace hardcoded placeholders like "system_patch_user" in todo/views/task.py.
Learnt from: AnujChhikara
PR: Real-Dev-Squad/todo-backend#119
File: todo/repositories/task_repository.py:149-154
Timestamp: 2025-07-09T19:59:31.694Z
Learning: In the todo-backend project, per product requirements, tasks marked as deleted (isDeleted=True) should still be returned in user task queries. The get_tasks_for_user method in TaskRepository should not filter out deleted tasks, unlike typical soft deletion patterns.
Learnt from: shobhan-sundar-goutam
PR: Real-Dev-Squad/todo-backend#95
File: todo/services/label_service.py:86-91
Timestamp: 2025-07-02T18:44:05.550Z
Learning: In the Real-Dev-Squad/todo-backend project, the GET v1/labels endpoint is designed to return only three fields in the response: id, name, and color. The prepare_label_dto method in todo/services/label_service.py intentionally excludes other LabelDTO fields like createdAt, updatedAt, createdBy, and updatedBy from the API response.
todo/serializers/get_tasks_serializer.py (1)
Learnt from: shobhan-sundar-goutam
PR: Real-Dev-Squad/todo-backend#95
File: todo/views/label.py:21-21
Timestamp: 2025-07-02T18:28:01.803Z
Learning: In Django REST Framework serializers, when a CharField has default="" specified, the validated_data will always contain a string value (empty string if parameter not provided) rather than None, making None-checks unnecessary when accessing that field from validated_data.
todo/views/task.py (1)
Learnt from: AnujChhikara
PR: Real-Dev-Squad/todo-backend#119
File: todo/repositories/task_repository.py:149-154
Timestamp: 2025-07-09T19:59:31.694Z
Learning: In the todo-backend project, per product requirements, tasks marked as deleted (isDeleted=True) should still be returned in user task queries. The get_tasks_for_user method in TaskRepository should not filter out deleted tasks, unlike typical soft deletion patterns.
todo/tests/integration/test_task_sorting_integration.py (2)
Learnt from: AnujChhikara
PR: Real-Dev-Squad/todo-backend#119
File: todo/repositories/task_repository.py:149-154
Timestamp: 2025-07-09T19:59:31.694Z
Learning: In the todo-backend project, per product requirements, tasks marked as deleted (isDeleted=True) should still be returned in user task queries. The get_tasks_for_user method in TaskRepository should not filter out deleted tasks, unlike typical soft deletion patterns.
Learnt from: VaibhavSingh8
PR: Real-Dev-Squad/todo-backend#83
File: todo/tests/unit/services/test_user_service.py:37-43
Timestamp: 2025-06-17T18:59:14.368Z
Learning: UserRepository.create_or_update is a static method in the todo application, so it should be mocked directly on the class rather than on an instance.
todo/services/task_service.py (1)
Learnt from: AnujChhikara
PR: Real-Dev-Squad/todo-backend#119
File: todo/repositories/task_repository.py:149-154
Timestamp: 2025-07-09T19:59:31.694Z
Learning: In the todo-backend project, per product requirements, tasks marked as deleted (isDeleted=True) should still be returned in user task queries. The get_tasks_for_user method in TaskRepository should not filter out deleted tasks, unlike typical soft deletion patterns.
todo/repositories/task_repository.py (1)
Learnt from: AnujChhikara
PR: Real-Dev-Squad/todo-backend#119
File: todo/repositories/task_repository.py:149-154
Timestamp: 2025-07-09T19:59:31.694Z
Learning: In the todo-backend project, per product requirements, tasks marked as deleted (isDeleted=True) should still be returned in user task queries. The get_tasks_for_user method in TaskRepository should not filter out deleted tasks, unlike typical soft deletion patterns.
🧬 Code Graph Analysis (1)
todo/repositories/task_repository.py (3)
todo/models/task.py (1)
TaskModel(23-43)todo/repositories/common/mongo_repository.py (1)
get_collection(17-20)todo/repositories/assignee_task_details_repository.py (2)
AssigneeTaskDetailsRepository(9-107)get_by_assignee_id(41-52)
🪛 GitHub Actions: Tests
todo/tests/integration/test_task_sorting_integration.py
[error] 52-52: AssertionError: expected call not found. Expected call missing None argument, actual call has 'team_id=None'.
[error] 106-106: AssertionError: expected call not found. Expected call missing None argument, actual call has 'team_id=None'.
[error] 39-39: AssertionError: expected call not found. Expected call missing None argument, actual call has 'team_id=None'.
[error] 75-75: AssertionError: expected call not found for sort_field='createdAt'. Expected call missing None argument, actual call has 'team_id=None'.
[error] 75-75: AssertionError: expected call not found for sort_field='dueAt'. Expected call missing None argument, actual call has 'team_id=None'.
[error] 75-75: AssertionError: expected call not found for sort_field='priority'. Expected call missing None argument, actual call has 'team_id=None'.
[error] 75-75: AssertionError: expected call not found for sort_field='assignee'. Expected call missing None argument, actual call has 'team_id=None'.
[error] 87-87: AssertionError: expected call not found. Expected call missing None argument, actual call has 'team_id=None'.
[error] 27-27: AssertionError: expected call not found. Expected call missing None argument, actual call has 'team_id=None'.
🔇 Additional comments (9)
schema.yaml (1)
411-415: LGTM: Well-documented API parameter additionThe
teamIdquery parameter is properly defined with clear documentation and correct typing. The optional nature aligns with the filtering use case.todo/serializers/get_tasks_serializer.py (1)
38-38: LGTM: Proper serializer field configurationThe
teamIdfield is correctly configured as optional with appropriate validation rules. Theallow_blank=Falseandallow_null=Truesettings are suitable for this filtering parameter.todo/views/task.py (2)
48-54: LGTM: Consistent API documentationThe OpenAPI parameter documentation follows the same pattern as other query parameters and provides clear information about the filtering capability.
91-91: LGTM: Proper parameter extraction and forwardingThe
teamIdparameter is correctly extracted from validated data and passed to the service layer, following the established pattern for other parameters.Also applies to: 98-98
todo/services/task_service.py (2)
62-62: LGTM: Well-designed parameter additionThe
team_idparameter is added with a sensible default value ofNone, maintaining backward compatibility while enabling the new filtering functionality.
67-68: LGTM: Consistent parameter forwardingThe
team_idparameter is correctly passed to both repository methods using keyword arguments, maintaining consistency with the existing codebase pattern.todo/repositories/task_repository.py (3)
18-20: Method signature updated correctly to support team filtering.The addition of the
team_idparameter with a default value ofNonemaintains backward compatibility while enabling the new team-based filtering functionality.
71-71: Method signature updated correctly for consistency.The
countmethod signature change matches thelistmethod, maintaining consistency in the repository interface.
73-79: Team filtering logic in count method mirrors list method correctly.The implementation correctly duplicates the team filtering logic from the
listmethod, ensuring consistent behavior between counting and listing operations. The query filter construction is identical, which is appropriate.
… assertions - Adjusted assertions in `TaskServiceTests` and `TaskServiceSortingTests` to include a `None` parameter in the `mock_list` calls, ensuring alignment with the updated method signature. - Enhanced test coverage for task retrieval scenarios by reflecting the latest changes in the `TaskRepository` interface.
- Modified assertions in various test files, including `TaskSortingIntegrationTest`, `TaskPaginationIntegrationTest`, `TaskServiceTests`, and `TaskViewTests`, to include `team_id=None` in the `mock_list` and `mock_get_tasks` calls. - Ensured consistency across tests by aligning with the updated method signatures that now require the `team_id` parameter for task retrieval.
…k view tests - Reformatted the `mock_get_tasks` call in `TaskViewSortingTests` to enhance readability by breaking parameters into multiple lines. - Ensured consistency with previous updates that included the `team_id` parameter in task retrieval assertions.
2 participants
Description by Korbit AI
What change is being made?
Add
teamIdas a query filter for task retrieval and update related logic in the task repository, serializers, and views to support filtering tasks assigned to teams.Why are these changes being made?
These changes enable users to filter tasks by a specific team, enhancing the task management functionality to accommodate team-based task assignments. This approach efficiently integrates the team filtering logic within existing methods, providing a streamlined solution without altering fundamental task retrieval operations.