Skip to content
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

[Bug]: From Name is not setting properly in Calendar invitations created from Thunderbird #45081

Closed
5 of 8 tasks
GalacticWave opened this issue Apr 27, 2024 · 7 comments · Fixed by #45098
Closed
5 of 8 tasks
Assignees
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 29-feedback bug

Comments

@GalacticWave
Copy link

⚠️ This issue respects the following points: ⚠️

Bug description

When sending calendar invite from Thunderbird or other CalDAV supported calendars, the From Name is not correct. When sent from within nextcloud web UI, the invitation email is sent with From name being "user via nextcloud". But when the calendar event is created from Thunderbird, the invitation email is sent with From name being "nextcloud".

I wasn't sure if this is related to this issue - #5080 because I am not asking to chagne the from email Address. I am reporting an issue with the from name. I also have a fix for this. So, I thought that I can create a new issue and try to send a PR for this fix

Steps to reproduce

These steps work fine:

  1. Login to NextCloud Web UI.
  2. Open the Calendar App.
  3. Add a new event in the Calendar
  4. The invitation email sent from the server contains the From name "User via Nextcloud"

These steps produces the issue:

  1. Add/Connect the Nexcloud CalDAV in Thunderbird (or any email client that supports CalDAV
  2. Ensure that the calendar is setup to leverage server side scheduling
  3. Add a new event in the Calendar
  4. The invitation email sent from the server contains the From name "Nextcloud"

Expected behavior

The invitation email sent from the server when the calendar event is created in Thurderbird should also be "User via Nextcloud".

Installation method

None

Nextcloud Server version

29

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

@GalacticWave GalacticWave added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Apr 27, 2024
@GalacticWave
Copy link
Author

GalacticWave commented Apr 27, 2024

I have isolated the issue to be on this file - /nextcloud/apps/dav/lib/CalDAV/Schedule/IMipPlugin.php around line 217:

// Try to get the sender name from the current user id if available.
if ($this->userId !== null && ($senderName === null || empty(trim($senderName)))) {
$senderName = $this->userManager->getDisplayName($this->userId);
}

When the event is created on Thunderbird, there is no userID set and that's why the sender name defaults to the default "Nextcloud". I propose to rewrite this secton this way:

$sender = substr($iTipMessage->sender, 7);

// Try to get the sender name from the current user id or from sender if available.
if ($senderName === null || empty(trim($senderName))) {
if ($this->userId !== null){
$senderName = $this->userManager->getDisplayName($this->userId);
} else {
$senderName = $this->userManager->getDisplayName($sender);
}
}

Basically use the Sender from the iTipMessage object when userID is also null.

@kesselb
Copy link
Contributor

kesselb commented Apr 28, 2024

@SebastianKrupinski
Copy link
Contributor

Issue confirmed.

@GalacticWave your solution will not work. userManager->getDisplayName() requires a NC UID and $iTipMessage->sender() at this point is a email address.

@SebastianKrupinski
Copy link
Contributor

Diagnosed.

This an upstream issue caused by a fresh session with no cookie information. Causes userId to be null.

@GalacticWave
Copy link
Author

I found that email address is the userID used in the Database. Hence, I simply used the sender which is also email address. Mabye because on my server, I used the email address as the username as well for all the accounts created. But seems like there is more to this that I didn't consider.

The thing I can think of now is whether its possible to get the First and Last name from the user DB by querying using email address. But didn't find any existing functions or user cache functions that can do that.

@SebastianKrupinski
Copy link
Contributor

Querying the database for email address will not work, as email address are NOT unique. You can have multiple users with the same email address, but userId are unique.

@st3iny
Copy link
Member

st3iny commented Apr 29, 2024

Something isn't right with the authentication. The property $userId is injected via our DI. It seems to be null but this shouldn't be the case if the request is authenticated (which it is via the user and (app) password that Thunderbird is using).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap 29-feedback bug
Projects
Status: ☑️ Done
Development

Successfully merging a pull request may close this issue.

5 participants