Skip to content

Conversation

junaid-shirur
Copy link
Collaborator

@junaid-shirur junaid-shirur commented Oct 22, 2025

Description

https://juspay.atlassian.net/browse/XYNE-225?atlOrigin=eyJpIjoiNTIzNzAxMmE0NjViNDg1YmEyZGY2MmJiMDQ4YzI4ZWQiLCJwIjoiaiJ9

Testing

Additional Notes

Summary by CodeRabbit

  • Bug Fixes

    • Calendar invitation emails now have restricted access so only the invited user's email is listed in the permissions, preventing broader visibility.
  • Chores

    • Added and ran a migration that normalizes permissions for existing calendar emails, with progress logging and a summary of updated vs already-correct items.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @junaid-shirur, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where calendar event invitation emails were leading to incorrect or duplicated permission assignments. By implementing a conditional check based on the mailId, the system now accurately identifies calendar-related mails and assigns permissions solely to the current user, thereby streamlining the process and preventing redundant entries.

Highlights

  • Calendar Event Mail Handling: Introduced specific logic within the parseMail function to identify and handle calendar event invitation emails differently.
  • Permission De-duplication: For mails identified as calendar event invitations (via mailId starting with 'calendar-'), the permissions are now set exclusively to the userEmail to prevent de-duplication issues caused by unique emails sent to each attendee.
  • Streamlined Permission Assignment: The change ensures that calendar event mails, which often have unique subject lines for each attendee, correctly assign permissions to only the primary user, avoiding the inclusion of all attendees in the permissions array.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

The pull request addresses the de-duplication of event emails by modifying the logic for determining email permissions. Specifically, it introduces a conditional check based on whether the mailId starts with calendar-, and if so, sets the permissions to only include the userEmail. This change aims to prevent duplicate indexing of calendar event invitation emails where each attendee receives a unique email with their name in the subject line. The review focuses on the correctness and potential implications of this change.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 22, 2025

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

parseMail now treats mails with IDs starting with "calendar-" as calendar invitations and sets their permissions to a single-element array containing the current user email; other mails continue to collect unique From/To/Cc/Bcc addresses. A new migration script updates stored calendar-mail permissions accordingly.

Changes

Cohort / File(s) Summary
Gmail integration permission logic
server/integrations/google/gmail/index.ts
Adjusted parseMail to detect mailId prefixed with calendar- and set permissions to [currentUserEmail]; non-calendar mails retain previous behavior of aggregating unique From/To/Cc/Bcc addresses (lowercased).
Migration script for calendar mails
server/scripts/fix-calendar-mail-permissions.ts
Added a Bun script that queries calendar-related mail documents in batches, computes expected single-user permissions from each document's user map, updates documents whose permissions differ, logs progress, and exits with status 0/1.

Sequence Diagram(s)

sequenceDiagram
    participant Gmail as Gmail parseMail
    participant Parser as parseMail logic
    participant Store as Document store

    Gmail->>Parser: provide mail data (mailId, headers, userMap)
    alt mailId starts with "calendar-"
        Parser->>Parser: compute permissions = [currentUserEmail]
    else other mail
        Parser->>Parser: collect unique From/To/Cc/Bcc (lowercased)
    end
    Parser->>Store: attach computed permissions to mail record
Loading
sequenceDiagram
    participant Runner as fix-calendar-mail-permissions
    participant Vespa as Vespa query/update API
    participant Logger as Logger

    Runner->>Vespa: queryCalendarEmails(offset, limit)
    Vespa-->>Runner: return documents + totalCount
    loop per document
        Runner->>Runner: determine expectedPermissions ([userEmail])
        alt permissions differ
            Runner->>Vespa: UpdateDocument("mail", docId, {permissions: expectedPermissions})
            Vespa-->>Runner: update result
            Runner->>Logger: log success/failure
        else already correct
            Runner->>Logger: increment alreadyCorrect
        end
    end
    Runner->>Logger: log totals (totalFixed, alreadyCorrect)
    Runner->>Runner: process exit (0 on success, 1 on failure)
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested reviewers

  • zereraz
  • shivamashtikar
  • kalpadhwaryu
  • devesh-juspay

Poem

🐰 I hopped through mail and found a clue,
Calendar invites now belong to you.
One email holds the tiny key,
While others keep their company.
Hooray — permissions snug as can be! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Title Check ⚠️ Warning The title indicates that this pull request implements de-duplication of event mails, but the actual changes update permissions handling for calendar invitation emails and introduce a migration script to fix calendar mail permissions. There is no de-duplication logic in the modifications, making the title misleading and not representative of the main changes. Please update the title to reflect the true scope of the changes, for example “fix(mail): correct permissions for calendar invitation emails” or similar wording that highlights the permission adjustments and migration script.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ 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 fix/event_mails

📜 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 9cb0c70 and 8da726c.

📒 Files selected for processing (1)
  • server/scripts/fix-calendar-mail-permissions.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • server/scripts/fix-calendar-mail-permissions.ts

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.

Copy link
Contributor

@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: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7e50633 and 343d3b5.

📒 Files selected for processing (1)
  • server/integrations/google/gmail/index.ts (1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: naSim087
PR: xynehq/xyne#484
File: server/integrations/google/gmail-worker.ts:293-294
Timestamp: 2025-05-28T10:55:46.701Z
Learning: There are two separate `parseMail` functions in the codebase: one in `server/integrations/google/gmail-worker.ts` with signature `(email, gmail, client, userEmail)` returning `{ mailData, insertedPdfCount, exist }`, and another in `server/integrations/google/gmail/index.ts` with signature `(email, gmail, userEmail, client, tracker?)` returning `{ mailData, exist }`. Each file calls its own local version correctly.
📚 Learning: 2025-05-28T10:55:46.701Z
Learnt from: naSim087
PR: xynehq/xyne#484
File: server/integrations/google/gmail-worker.ts:293-294
Timestamp: 2025-05-28T10:55:46.701Z
Learning: There are two separate `parseMail` functions in the codebase: one in `server/integrations/google/gmail-worker.ts` with signature `(email, gmail, client, userEmail)` returning `{ mailData, insertedPdfCount, exist }`, and another in `server/integrations/google/gmail/index.ts` with signature `(email, gmail, userEmail, client, tracker?)` returning `{ mailData, exist }`. Each file calls its own local version correctly.

Applied to files:

  • server/integrations/google/gmail/index.ts

Copy link
Contributor

@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: 2

🧹 Nitpick comments (1)
server/scripts/fix-calendar-mail-permissions.ts (1)

16-19: Remove redundant hits parameter.

The hits parameter is redundant since the limit is already specified in the YQL query on line 14.

Apply this diff to remove the redundant parameter:

   const params = new URLSearchParams({
     yql,
-    hits: limit.toString(),
   })
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 343d3b5 and 9cb0c70.

📒 Files selected for processing (1)
  • server/scripts/fix-calendar-mail-permissions.ts (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
server/scripts/fix-calendar-mail-permissions.ts (2)
server/logger/index.ts (2)
  • getLogger (36-93)
  • Subsystem (15-15)
server/search/vespa.ts (1)
  • UpdateDocument (24-24)
🔇 Additional comments (4)
server/scripts/fix-calendar-mail-permissions.ts (4)

1-10: LGTM!

The shebang, imports, and logger initialization are correctly structured.


58-98: Permission extraction and update logic is sound.

The logic correctly:

  • Extracts the user email from userMap keys
  • Validates that a user exists before proceeding
  • Normalizes email to lowercase for consistent comparison
  • Skips documents that already have correct permissions (good optimization)
  • Handles individual update failures gracefully without aborting the entire migration

112-120: LGTM!

The script execution follows best practices with proper exit codes and error handling.


35-35: Review comment is outdated and does not reflect actual code.

The review comment shows data.root?.fields?.totalCount || 0, but the actual code at line 35 uses data.root?.fields?.n || 0. The current implementation follows the established codebase pattern where Vespa responses contain the total count in the n field, not totalCount. This is consistently applied across all Vespa query scripts (userConnectionData.ts, clear-vespa-data.ts, evaluateSearchQuality.ts, etc.) and validated by test fixtures. The reviewer's suggested alternative using .root.coverage.documents does not exist in the codebase.

Likely an incorrect or invalid review comment.

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.

1 participant