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

[GalacticWave]

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]

cc @ChristophWurst @miaulalala @SebastianKrupinski

[SebastianKrupinski]

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]

Diagnosed.

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

[GalacticWave]

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]

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]

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).