Closed
Bug 446666
Opened 16 years ago
Closed 16 years ago
"Send attendees invitations via email" checkbox is disabled (grayed out)
Categories
(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)
Calendar
E-mail based Scheduling (iTIP/iMIP)
Tracking
(Not tracked)
VERIFIED
FIXED
0.9
People
(Reporter: mozilla, Assigned: dbo)
Details
Attachments
(1 file, 2 obsolete files)
4.00 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Build Identifier: Lightning 0.9pre 2008-07-21 20 / Thunderbird 2.0.0.14 / WinXP "Send attendees invitations via email" is disabled (the checkbox and the label are grayed out) in the Event Dialog after I add an attendee and want to send an ICS invitation. There are actually two problems: (1) I can't toggle the checkbox and (2) it defaults to unchecked even though the pref "calendar.itip.sendemail" is set to true. I'm using a local ICS calendar (i.e. file:///...). There are no errors in the console. If I guess, I'd point to the patch in bug 431522 ("Can't add an invitation to an event if the same event is already in one of your calendars"). File: calendar/prototypes/wcap/sun-calendar-event-dialog.js Suspected code: if (!canNotifyAttendees(calendar, item) && calendar.getProperty("imip.identity")) { enableElement("send-invitations-checkbox"); } else { disableElement("send-invitations-checkbox"); } Reproducible: Always
Assignee | ||
Comment 1•16 years ago
|
||
Hi Pete, is there an email identity configured for the calendar (see calendar properties)?
Reporter | ||
Comment 2•16 years ago
|
||
(In reply to comment #1) > is there an email identity configured for the calendar (see calendar > properties)? I assumed that it would choose the default identity of the default account if I didn't specify one in the calendar properties. It seems likely that other users who upgrade to the official 0.9 release might make the same mistake as me, so maybe the default (when upgrading or when creating a new calendar) could be changed from "None" to Thunderbird's default identity, or perhaps there could be a 0.9 release note. Anyway, I just set the identity in the calendar properties and now it seems to work okay -- wish I had thought of trying that cuz I knew the dropdown was recently added! Anyway, thanks. I guess this bug is "works for me".
Assignee | ||
Comment 3•16 years ago
|
||
(In reply to comment #2) > (In reply to comment #1) > > is there an email identity configured for the calendar (see calendar > > properties)? > > I assumed that it would choose the default identity of the default account if I > didn't specify one in the calendar properties. It seems likely that other > users who upgrade to the official 0.9 release might make the same mistake as > me, so maybe the default (when upgrading or when creating a new calendar) could > be changed from "None" to Thunderbird's default identity, or perhaps there > could be a 0.9 release note. Your assumption is correct, it should use the default account, i.e. <http://mxr.mozilla.org/mozilla1.8/source/calendar/providers/base/calProviderBase.js#72> This seems to fail on your profile. I suspect the reason is that there's no explicit default calendar set, thus getAccountManager().defaultAccount throws, there's no fallback to any account/identity.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-calendar0.9+
Reporter | ||
Comment 4•16 years ago
|
||
After more investigation, I think that I was burned again by using the Thunderbird extension "Folderpane Tools" which allows people to set the default account to "Local Folders" so that our RSS accounts appear at the bottom of the folder pane in Thunderbird. As you probably know, the "Local Folders" account has no identities. That problem was originally reported by klint in bug 374759. Philipp fixed it by submitting a patch in a different bug: bug 419349 comment 25. Since this will probably not affect very many users, I would understand if you think this is a low priority, and anyway people can work around the problem by manually selecting the email identity in the calendar properties. Otherwise, if you decide to work on calProviderBase.js again, I noticed a strange new boolean operator on line 51: !== It seems to evaluate to the same thing as != :) Also, if it helps, here are some relevant lines from my prefs.js, where account1 is "Local Folders" and account2 is my main email account. Only account2 has identities: user_pref("mail.accountmanager.accounts", "account1,account2"); user_pref("mail.accountmanager.defaultaccount", "account1"); user_pref("mail.accountmanager.localfoldersserver", "server1"); user_pref("mail.account.account1.server", "server1"); user_pref("mail.server.server1.hostname", "Local Folders"); user_pref("mail.account.account2.server", "server2"); user_pref("mail.server.server2.hostname", "mail.messagingengine.com"); user_pref("mail.account.account2.identities", "id1,id2,id4,id5,id3,id6");
Assignee | ||
Comment 5•16 years ago
|
||
Pete, could you please try to revert to your previous scenario, and try out this patch? thanks! About the strict comparison operators, see <http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Operators:Comparison_Operators>; those are in the mentioned code on purpose.
Reporter | ||
Comment 6•16 years ago
|
||
Unfortunately it didn't work. Here's my test code: } else { // take default account/identity: try { //var account = getAccountManager().defaultAccount; var account = null; try { account = getAccountManager().defaultAccount; WARN("1: Account is " + account); } catch (exc) { } if (!account && getAccountManager().accounts.Count()) { // take some account account = getAccountManager().accounts.getElementById(0).QueryInterface(Components.interfaces.nsIMsgAccount); WARN("2: Account is " + account); } if (account) { var identity = account.defaultIdentity; WARN("3: Identity is " + identity); if (!identity && account.identities.Count()) { identity = account.identities.getElementById(0).QueryInterface(Components.interfaces.nsIMsgIdentity); WARN("4: Identity is " + identity); } if (identity) { if (outAccount) { outAccount.value = account; } return identity; } } } catch (exc) { // any error, e.g. no account at all WARN("5: Caught exception " + exc); } WARN("6: Returning null"); return null; } And here's the output: Warning: 1: Account is [nsIMsgAccount: account1] Warning: 3: Identity is null Warning: 6: Returning null I think the problem is that the default account (account1) is a valid account ("Local Folders") but it has no identities. In this case, is it possible to use the default identity of account2 ? p.s. Thanks for enlightening me about the strict vs. non-strict operators. Interesting.
Comment 7•16 years ago
|
||
(In reply to comment #4) > That problem was originally reported by klint in bug 374759. Philipp fixed it > by submitting a patch in a different bug: bug 419349 comment 25. In that case I should probably fix it here too ;-)
Assignee: nobody → philipp
Attachment #330892 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #330979 -
Flags: review?(daniel.boelzle)
Assignee | ||
Updated•16 years ago
|
Attachment #330979 -
Flags: review?(daniel.boelzle) → review+
Reporter | ||
Comment 8•16 years ago
|
||
Sorry to be a pain, but it's throwing this: "caught exception TypeError: getAccountManager().accounts.getElementById is not a function" Also, I noticed that the variable 'identity' is defined inside the For block but referenced at the top of it and also after it. I obviously don't know much about JavaScript but the scoping rules seem strange compared to C++ land.
Assignee | ||
Comment 9•16 years ago
|
||
This should finally do it.
Assignee: philipp → daniel.boelzle
Attachment #330979 -
Attachment is obsolete: true
Attachment #331283 -
Flags: review?(philipp)
Reporter | ||
Comment 10•16 years ago
|
||
Okay, I think you fixed it. It works when I restart Thunderbird with my original storage.sbd file (i.e. the correct identity is automatically populated in each calendar's properties) and it works when I use the New Calendar wizard. Thanks to both of you for looking at this.
Updated•16 years ago
|
Attachment #331283 -
Flags: review?(philipp) → review+
Assignee | ||
Comment 11•16 years ago
|
||
Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → 0.9
You need to log in
before you can comment on or make changes to this bug.
Description
•