Fix request type impl #11758
Fix request type impl #11758
Conversation
amirmkia1997
requested review from
ChristophWurst,
GretaD and
kesselb
as code owners
|
Thank you for the PR! We will review it shortly |
src/components/Imip.vue
Outdated
| return false | ||
| } | ||
| const fromEmail = this.message.from[0].email?.toLowerCase() || '' | ||
| return fromEmail.endsWith('@digikala.com') |
There was a problem hiding this comment.
Could you please the purpose of this check?
There was a problem hiding this comment.
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.
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?
There was a problem hiding this comment.
Hi @ChristophWurst,
Thanks for the feedback! I’ve updated this part to make it more generic:
The trusted domains are now configurable via Admin Settings instead of being hardcoded.
The code reads the list of trusted domains from the settings, so any domain can be added and calendar events from those domains will appear automatically as tentative.
This makes the feature usable for all users, not just a single example domain.
There was a problem hiding this comment.
The app already has trusted senders. That is the list of senders for which the app shows external images by default. Reuse that, please.
There was a problem hiding this comment.
We tested the Trusted Senders feature, but there’s no button or visible option to add a trusted domain, even though we’re using the latest version of your app.
We also tried adding our domain (@digikala.com) directly to the database as admin, but that didn’t achieve what we’re aiming for — which is to have all emails from that domain automatically appear in the calendar.
It seems that the current trusted senders mechanism only affects image loading, not event handling.
Could you please guide us on how to properly achieve this behavior?
Thanks a lot for your help! 🙏
There was a problem hiding this comment.
Good point. You could add a UI option to edit trusted senders.
The auto-import of trusted senders is also something you have to add.
There was a problem hiding this comment.
As you can see in the screenshots, I’ve added the azarstan email from the database, and I can also see it in the panel under Trusted Senders.
However, when an email is sent from azarstan, it doesn’t get added to the calendar.
|
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.
This appears to be unrelated, no?
There was a problem hiding this comment.
You're right, it's not directly related. I noticed that in some cases incoming emails were not fully displayed — parts of the message body were being cut off. I added this change to fix that rendering issue and ensure the full email content is shown properly.
| return undefined | ||
| } | ||
| function findAttendeeByEmails(vEvent, emails) { |
There was a problem hiding this comment.
Hey, we recently changed the logic with #11915. Please ensure to rebase your branch and also re-test if that is still necessary.
| $this->initialStateService->provideInitialState( | ||
| Application::APP_ID, | ||
| 'digikala_domain', | ||
| $this->config->getAppValue('mail', 'digikala_domain', '@digikala.com'), |
There was a problem hiding this comment.
Hard coded domain names and vendor specific variables, are not a good solution
| existingEventFetched: false, | ||
| targetCalendar: undefined, | ||
| comment: '', | ||
| digikalaDomain: loadState('mail', 'digikala_domain', '@digikala.com'), |
There was a problem hiding this comment.
Hard coded domain names and vendor specific variables, are not a good solution
| isFromDigikala() { | ||
| if (!this.message.from || !this.message.from[0]) { | ||
| return false | ||
| } | ||
| const fromEmail = this.message.from[0].email?.toLowerCase() || '' | ||
| return fromEmail.endsWith(this.digikalaDomain) | ||
| }, | ||
There was a problem hiding this comment.
vendor specific variables and method names, are not a good solution
4 participants
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.