Skip to content

Conversation

@matheusysd
Copy link
Contributor

@matheusysd matheusysd commented Oct 14, 2025

During our latest run on jenkins https://jenkins.tsl.io/job/The%20Silverlogic/job/jeteye-backend/job/JETEYE-73-rebase-with-ba/2/console we saw a lint error inside the package

`➜ jeteye-backend git:(JETEYE-73-rebase-with-ba) ✗ tsl-bac lint
Skipped 3 files
reformatted /usr/src/app/baseapp-backend/baseapp_cloudflare_stream_field/tests/test_refresh_from_cloudfare.py

All done! ✨ 🍰 ✨
1 file reformatted, 1069 files left unchanged.`

Summary by CodeRabbit

  • Tests
    • Reformatted test setup to use a clearer multi-line context manager; no behavior changes.
  • Style
    • Minor formatting updates for consistency in tests.
  • Chores
    • Removed legacy database triggers via a migration.
  • Bug Fixes
    • Tightened unread notifications so counts are only shown to the authenticated account owner.
  • New Features
    • Exposed a read-only, non-writable superuser flag on user representations.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Oct 14, 2025

Walkthrough

Adds a Django migration that removes two pgtrigger triggers, tightens a GraphQL resolver to require the requesting user equal the target user before counting unread notifications, reformats a test’s multi-context with-statement (stylistic), and exposes is_superuser as a read-only private field on a user serializer.

Changes

Cohort / File(s) Summary
Test formatting refactor
baseapp_cloudflare_stream_field/tests/test_refresh_from_cloudfare.py
Reformatted a single-line multi-context with into a parenthesized multi-line with block; no behavioral changes.
Migration: remove pgtrigger triggers
baseapp_chats/migrations/0011_remove_message_create_message_status_and_more.py
New Django migration adding pgtrigger.migrations.RemoveTrigger operations to drop triggers: create_message_status (model message) and increment_unread_count (model messagestatus); depends on 0010_message_deleted.
GraphQL resolver security tightening
baseapp_notifications/graphql/object_types.py
resolve_notifications_unread_count now requires both info.context.user.is_authenticated and info.context.user == self before returning a count.
Serializer visibility change
baseapp_auth/rest_framework/users/serializers.py
Added is_superuser to UserBaseSerializer.Meta.fields, marked it in Meta.private_fields and Meta.read_only_fields (exposed internally, read-only).

Sequence Diagram(s)

sequenceDiagram
    actor Client
    participant GraphQL as Notifications Resolver
    participant App as Application / DB

    Client->>GraphQL: query notificationsUnreadCount(targetUserId)
    GraphQL->>GraphQL: check info.context.user.is_authenticated
    alt authenticated
        GraphQL->>GraphQL: check info.context.user == self (target user)
        alt same user
            GraphQL->>App: count unread notifications for target user
            App-->>GraphQL: unreadCount
            GraphQL-->>Client: unreadCount
        else not same user
            GraphQL-->>Client: 0 (or no access)
        end
    else not authenticated
        GraphQL-->>Client: 0 (or no access)
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Files/areas to pay extra attention to:

  • Migration file: ensure trigger names and model names match DB state and previous migrations.
  • Serializer changes: confirm adding is_superuser to private_fields and read_only_fields meets visibility expectations.
  • GraphQL resolver: verify that self correctly refers to the target user instance in all call sites.

Poem

I twitch my whiskers, hop and bind,
Triggers pruned and checks aligned.
Contexts wrapped in tidy rows,
A hidden flag in velvet shows.
Rabbit claps — neat code, sweet find. 🐇✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check ❓ Inconclusive The PR title 'Lint fixes' is vague and does not clearly describe the actual changes, which include formatting refactoring, Django migrations, authentication logic tightening, and serializer field modifications. Consider a more specific title that captures the scope of changes, such as 'Refactor formatting, update migrations, and enhance auth logic' or break into separate PRs if these are unrelated changes.
✅ Passed checks (1 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch hotfix/lint-test-refresh-from-cloudflare

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 27f1826 and 1800233.

📒 Files selected for processing (1)
  • baseapp_auth/rest_framework/users/serializers.py (2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: tests (3.12, 5.2.1)
  • GitHub Check: tests (3.12, 4.2.15)
🔇 Additional comments (1)
baseapp_auth/rest_framework/users/serializers.py (1)

75-75: Let me search the codebase to understand how JWT_CLAIM_SERIALIZER_CLASS is used:

Based on my research, I can see that JWT_CLAIM_SERIALIZER_CLASS is configured to use UserBaseSerializer in baseapp_auth. This is critical because if the serializer's fields are used to populate JWT token claims, the is_superuser field would be embedded in every JWT token issued, exposing sensitive user information.

The key security issue is that adding is_superuser to UserBaseSerializer.fields could mean it appears in JWT tokens (which are signed but not encrypted, so data is readable). This is distinct from the API-level protections (private_fields, read_only) already in place.

Security & Inconsistency: PR titled "Lint fixes" contains functional changes exposing is_superuser

While the field is properly marked read-only and in private_fields for API endpoints, adding it to UserBaseSerializer.fields is a functional change that contradicts the PR description. More critically:

  • If JWT_CLAIM_SERIALIZER_CLASS uses these serializer fields, is_superuser will be embedded in JWT tokens (readable to anyone with the token)
  • Even though the field is sensitive, broadcasting it in tokens needs explicit justification and testing
  • No explanation provided for why this field exposure is necessary

Verify:

  1. Does BaseJwtLoginSerializer embed UserBaseSerializer.fields into JWT tokens?
  2. What is the business requirement for exposing is_superuser?
  3. Has this change been tested to ensure superuser status isn't leaked via tokens?

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@matheusysd
Copy link
Contributor Author

matheusysd commented Oct 20, 2025

Wait to merge this PR we will add more issues we found on our project

  • wait

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2598fb0 and 27f1826.

📒 Files selected for processing (2)
  • baseapp_chats/migrations/0011_remove_message_create_message_status_and_more.py (1 hunks)
  • baseapp_notifications/graphql/object_types.py (1 hunks)
🧰 Additional context used
🪛 Ruff (0.14.0)
baseapp_chats/migrations/0011_remove_message_create_message_status_and_more.py

9-11: Mutable class attributes should be annotated with typing.ClassVar

(RUF012)


13-22: Mutable class attributes should be annotated with typing.ClassVar

(RUF012)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: tests (3.12, 4.2.15)
  • GitHub Check: tests (3.12, 5.2.1)
🔇 Additional comments (1)
baseapp_chats/migrations/0011_remove_message_create_message_status_and_more.py (1)

7-22: Verify that trigger functionality is preserved in application code.

The migration correctly removes two database triggers, but this is a significant functional change—not a lint fix. The removed triggers likely automated:

  • create_message_status: Auto-creation of message status records
  • increment_unread_count: Maintaining unread message counts

Ensure this logic is now handled in application code (e.g., model signals, GraphQL mutations, or service layer).

Run the following script to verify trigger definitions and find replacement logic:

#!/bin/bash
# Find the original trigger definitions and verify replacement logic exists

echo "=== Searching for trigger definitions ==="
rg -n "create_message_status|increment_unread_count" --type py -C 3

echo -e "\n=== Searching for message status creation logic ==="
rg -n "MessageStatus.*create|MessageStatus.*save" --type py -C 2

echo -e "\n=== Searching for unread count logic ==="
rg -n "unread.*count|increment.*unread" --type py -C 2

echo -e "\n=== Checking for pgtrigger decorators in models ==="
ast-grep --pattern $'@pgtrigger.$$$
class $_ {
  $$$
}'

Note on static analysis warnings: The Ruff RUF012 warnings about ClassVar annotations are false positives. Django's migration framework intentionally uses dependencies and operations as plain class attributes—this is the standard pattern across all Django projects.

Comment on lines 30 to 33
def resolve_notifications_unread_count(self, info):
if self.is_authenticated:
if info.context.user.is_authenticated and info.context.user == self:
return Notification.objects.filter(recipient=self, unread=True).count()
return 0
Copy link

@coderabbitai coderabbitai bot Oct 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Good security improvement, but PR title is misleading.

This authorization check properly restricts unread notification count queries to authenticated users viewing their own data, consistent with the other resolvers in this interface (lines 36, 43, 48).

However, the PR title "Lint fixes" is misleading. This is a behavioral change that tightens security by adding an authorization guard that was previously missing. Consider updating the PR description to explicitly document this security improvement rather than categorizing it as just a lint fix.

🤖 Prompt for AI Agents
In baseapp_notifications/graphql/object_types.py around lines 30 to 33, the
change adds an authorization guard to restrict unread notification count queries
to authenticated users viewing their own data (a behavioral/security change) but
the PR title and description still say "Lint fixes"; update the PR title to
something like "Add authorization guard for unread notifications count" and
update the PR description to explicitly document the behavioral change and
security rationale (what was changed, why it tightens access, and any related
lines/resolvers), and mention that tests or changelog entries were updated if
applicable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matheusysd can you fix PR title please?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

Comment on lines 30 to 33
def resolve_notifications_unread_count(self, info):
if self.is_authenticated:
if info.context.user.is_authenticated and info.context.user == self:
return Notification.objects.filter(recipient=self, unread=True).count()
return 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matheusysd can you fix PR title please?

@vitorguima vitorguima self-requested a review December 3, 2025 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants