-
Notifications
You must be signed in to change notification settings - Fork 286
Fix request type impl #11758
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Fix request type impl #11758
Conversation
Thank you for the PR! We will review it shortly |
return false | ||
} | ||
const fromEmail = this.message.from[0].email?.toLowerCase() || '' | ||
return fromEmail.endsWith('@digikala.com') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please the purpose of this check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We wanted to have a place to define trusted domains — so that whenever we receive a calendar event from one of those domains, it can automatically appear in the calendar as tentative.
In this case, this domain was just an example of one of our trusted sources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this fits your personal use case it needs a more generic approach to be usable for others too. How about changing this so it's based on trusted domains?
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
enhancedBody() { | ||
return this.body.replace(/(^>.*\n)+/gm, (match) => { | ||
return `<details class="quoted-text"><summary>${t('mail', 'Quoted text')}</summary>${match}</details>` | ||
return `<details class="quoted-text" open><summary>${t('mail', 'Quoted text')}</summary>${match}</details>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to be unrelated, no?
return undefined | ||
} | ||
function findAttendeeByEmails(vEvent, emails) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, we recently changed the logic with #11915. Please ensure to rebase your branch and also re-test if that is still necessary.
Summary
This pull request continues the work from issue #6997
by improving how incoming calendar invitations are processed and ensuring that event data is written to the correct calendar.
It also fixes a separate bug where certain incoming emails were not rendered completely in the Mail app.
Background
Currently, when a user receives an iTIP/IMip “REQUEST” message (calendar invitation), the system has no clear rule for selecting the target calendar. As a result, invitations may not appear automatically, and users must manually import them. In addition, some emails—especially those with complex multipart content—were displayed only partially, causing users to miss information.
Proposed Changes
Calendar Invitation Handling
Added an if clause in IMipService::process to check for messages of type REQUEST.
Implemented logic to:
Detect and use a user-defined default “invitation calendar” (stored in oc_preferences) or, if not set, fall back to the personal calendar.
Call ICreateFromString::createFromString to create the event in the chosen calendar.
Mark the message as processed, or as erroneous if storing fails.
Added a frontend settings field so users can configure their preferred invitation calendar.
Email Display Fix
Corrected message parsing to ensure full rendering of emails with multipart or complex MIME structures, resolving the issue where some messages were only partially shown.
Testing
Verified that invitations from both internal and external domains are correctly stored in the selected calendar and reflected in the Calendar app.
Tested fallback behavior when no default calendar is set.
Confirmed that previously problematic emails now display their entire content across major browsers.
Notes
This update streamlines the handling of calendar invitations, reduces manual steps for users, and improves reliability in email rendering.