2010372 - invites not recogized as invites anymore (treated as own events)

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Magnus Melin [:mkmelin]]

It seems something has broken wrt invites.
Receive an invite which has been added to the calendar server side. Click "Details...". Edit Event opens, instead of the event summary dialog with buttons to accept or not.
I also see this for other recurring events in my calendar.

Comment 1

[Martin Giger [:freaktechnik]]

Some more details:

• This only reproduces when you have more than two email accounts set up and the owner email in the calendar properties shouldn't be your primary email address
• With builds where this happens the email field in the calendar properties always resets to the primary email address, no matter what other value you choose.

I got a regression window of https://hg-edge.mozilla.org/comm-central/pushloghtml?fromchange=671cf534d3777086ad0ff945dbe3410e6592f9a6&tochange=d9cd5b0e1c14f608b250e042c4fc6178938f8cdf which would confirm my suspicion of this being related to bug 1987654

Comment 2

[Lorenz Pressler]

please specify, what is a wrt invite?
the calendar is caldav?
what are the calendar users the server has set, is the configured identity one of these addresses? and which identity is the invite addressed to?

Comment 3

[Martin Giger [:freaktechnik]]

wrt -> with regards to
I assume Magnus is also seeing this with his work Google Calendar. So in regards to your technical questions "whatever google does for a personal calendar"... The invites are usually for the email the calendar should belong to, but for some reason, as I said, the email in the calendar properties doesn't get persisted/set correctly.

Comment 4

[Lorenz Pressler]

oh my.. the google calender is caldav calendare afaik. but maybe somehow it is handled in another was a normal caldav calendar is handled. what i have experienced the configured identitiy is ignored for all caldav calendars i tested (except sent-by checks). but apparently is is not for google calendars from your experience.. i will need to play around a bit to find out where the code path differs for different type of calendars.

Comment 5

[Lorenz Pressler]

Attachment: fix fillACLProperties to honor configured calendar identity

this should fix it, but i have to test it with other caldav providers first

Comment 6

[Lorenz Pressler]

that should also address some other bugreports about not honoring the configured identity in the preferences for caldav calendars that actually return users for the calendar, not like google

Comment 7

[Lorenz Pressler]

Attachment: Bug 2010372 - invites not recogized as invites anymore (treated as own events). r=mkmelin

Comment 8

[Magnus Melin [:mkmelin]]

So for me this was a gmail calendar. For some reason the calendar had the wrong one of my emails set in the calendar settings.
Perhaps earlier that didn't matter... hmm. Anyway, your patch does fix it for me.

Comment 9

[Lorenz Pressler]

(In reply to Magnus Melin [:mkmelin] from comment #8)

So for me this was a gmail calendar. For some reason the calendar had the wrong one of my emails set in the calendar settings.
Perhaps earlier that didn't matter... hmm. Anyway, your patch does fix it for me.

no, i introduced a fallback that wasn't falling back to what I thought it would fall back. Actually I made caldav calendars that did not have users set on the server behave like the other ones that do. This introduced the bugs that exist for the other caldav users now also to you.
The patch should fix for everyone: use the identity configured in thunderbird for the calendar as organizer (overriding server settings) and use it also to determine isInvite status (additional to any server set addresses)

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/61b7c1b103d1
invites not recogized as invites anymore (treated as own events). r=mkmelin

Comment 11

[Lorenz Pressler]

Comment on attachment 9542064 [details]
Bug 2010372 - invites not recogized as invites anymore (treated as own events). r=mkmelin

Uplift Approval Request

• Please state case for uplift consideration and ensure bug severity is set: Regression of Bug 1987654 that breaks caldav calendars that do not advertise a user-address-set.
• User impact if declined: all google calendars have a broken isInvite logic, no RSVP possible, wrong set organizer for new created events (if default identity differs from calendar owner)
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Daily?: Yes
• Has the fix been verified in Beta?: Yes
• Needs manual test from QA?: No
• If yes, steps to reproduce: testunit was included in the patch.
  I don't think it needs further testing from QA but:
  add email account;
  add gmail account + calender
  first email account is default identity
  set gmail address as calendar identity in preferences
  -> create new event: organizer is the default identity and not the gmail
  -> invites not recognized as invites
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): very local changes, only affects caldav, the used functions are not used anywhere else.
• Does the fix cause any migrations to be skipped?: Yes
• String changes made/needed:

Comment 12

[Lorenz Pressler]

btw this fixes also this bug 603320

Comment 13

[Martin Giger [:freaktechnik]]

(In reply to Lorenz Pressler from comment #11)

Comment on attachment 9542064 [details]

• Does the fix cause any migrations to be skipped?: Yes

I don't believe this patch touches any migrations, so this is actually No. The string changes question is also a no, as there are no string changes in the patch.

Comment 14

[Corey Bryant]

• Has the fix been verified in Beta?: Yes

This hasn't been tested in beta either. Let's try to answer these questions accurately, or else there's no point in filling them out.

Comment 15

[Corey Bryant]

Comment on attachment 9542064 [details]
Bug 2010372 - invites not recogized as invites anymore (treated as own events). r=mkmelin

[Triage Comment]
Approved for beta

Comment 16

[Daniel Darnell [:dandarnell]]

Thunderbird 148.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/2e11875e3bdc

Comment 17

[Lorenz Pressler]

(In reply to Corey Bryant from comment #14)

• Has the fix been verified in Beta?: Yes

This hasn't been tested in beta either. Let's try to answer these questions accurately, or else there's no point in filling them out.

I did test it on the beta branch to verify. but this had to be done differently i guess?
the thing about migrations was a lapse from my side, don't know how this happened, I am sorry to cause confusion.
thank you for your patience with me.

Comment 18

[Corey Bryant]

(In reply to Lorenz Pressler from comment #17)

(In reply to Corey Bryant from comment #14)

• Has the fix been verified in Beta?: Yes

This hasn't been tested in beta either. Let's try to answer these questions accurately, or else there's no point in filling them out.

I did test it on the beta branch to verify. but this had to be done differently i guess?
the thing about migrations was a lapse from my side, don't know how this happened, I am sorry to cause confusion.
thank you for your patience with me.

Ok you must have tested locally with beta. Thank you for doing that, and apologies for the confusion on my end. Generally that question refers to uplifts to the Release channel and whether they were tested in beta.