After the account is created, don't allow editing the user name. We want to
prevent this as the user name is core to the account and changing the user
name is tantamount to creating a new account.
bug 3502279
Change-Id: I1d89710fd48aca67ba13abea5bdbdc1d87941618
We now allow a single global character ['*'] to be specified somewhere in
the domain attribute. Additionally, we will replace the string "$domain"
with the matched domain in all attributes -- user name, password and URIs.
bug 4090086
Change-Id: I46a637ed364c1a079e1230fa22393a1bac059b1f
- Menu now works
- Removed a lot of unnecessary/soon-to-be-unnecessary code.
Especially,
- multi-selection panel is now replaced with CAB
- SetTitleTask will be replaced with a loader
- Removed the option menu xml for magic mailboxes
(The regular one should work for them as well)
Bug 4184142
Change-Id: I52adff6d711232d536b6f00367a240e1faeea14b
Modified location of the test to processUploadMessage() method. We do this to
prevent creating multiple EmailContent.Message objects.
Bug: 4096266
Backport from: Id83d3703283c0cd89a60c6210976093d39fb6934
Change-Id: Ie0e9c52182df96617cc942235135ef5ccf865d41
* This fix may resolve the bugs referenced below; the issue fixed
could cause pandemonium after the server commands a wipe of calendar
data and most likely explains these issues (via Occam's Razor)
* Also backport a SQL fix to more reliably delete calendar data
Bug: 4077499
Bug: 4064237
Backport from: I628fb14ea2c04150d4f27341751f0eab61ee33d1
Change-Id: I7667a11663d8720a92b9eba0748f60256a25edba
The attachment info may be null when we attempt to mark them for
downloading. Add a null-check before we try to dereference the info
structure.
Bug: 4053184
Backport of: I831e3abd100664c92f7af585014a03250e40ff64
Change-Id: Iffdf8cdc3a17c0ab691596eb9e240ef87acb2e37
On exchange servers that support "smart reply", the original message is
actually appended by the server. In this situation, we should not append
the original HTML text on the client.
bug 4177192
Change-Id: I0bdb34cf837e0cc0bfac8917f993ecb764814d97
* This happens if an open fails immediately (error message in the
initial banner) followed by a checkSettings.
* The fix is to harden checkSettings to force a clean connection
every time.
Bug: 2170147
Backport of: If7403bf517477d2b03b21d71caab511fe45e234c
Change-Id: Ia6cc0e3ab0c8a8a78b5d8b8fb7b8ba4b4cdd3ef2
On exchange servers that support "smart reply", the original message is
actually appended by the server. In this situation, we should not append
the original HTML text on the client.
but 4177192
Change-Id: I6fad74ac761e2abfe7cb0f536df4db30f7d5ca9a
We were always loading from the network for HTML messages. Now we don't
load from the network until the user clicks the "display images" button.
Change-Id: I4cdfea5e5338f3bba70b3d04df6551516d3e1a85
If an IMAP server supports the UIDPLUS capability, it can return the new UID
as part of the response to the "UID COPY" command. However, if the server does
not support UIDPLUS, we perform a SEARCH to try to determine the new message
UID.
This is the second of a couple modifications.
bug 4092301
Change-Id: I1f548b63becfec8733cb8ba9a3fe6ff4be6fdd83
We were always loading from the network for HTML messages. Now we don't
load from the network until the user clicks the "display images" button.
Change-Id: I1838b6cb09d49a2b521baa12a80239107391534f
When copying messages between mailboxes using standard IMAP, we must perform
a QUERY or FETCH in order to determine the new message UID. However, if the
server supports the UIDPLUS capability, the server will return the new UID
as part of the response to the "UID COPY" command.
This is the first of a couple modifications. We still need to fallback to a
less efficient QUERY/FETCH if the server does not support UIDPLUS.
bug 4092301
Change-Id: I9279f7fd70daf85adba3b3e202c12d67ddf91f22
Refactor the changes introduced in Ib02842bb.
- Now Welcome and AccountSettingsXL accept intents with URLs of the following
style, and get IDs from query params, rather than extras.
Welcome:
content://ui.email.android.com/view/mailbox?ACCOUNT_ID=1&MAILBOX_ID=2&MESSAGE_ID=3
AccountSettingsXL:
content://ui.email.android.com/settings?ACCOUNT_ID=1
- Now the "new message" and "login failed" notifications use these new style
intents, so the system wouldn't merge PendingIntents for different accounts.
Also:
- Moved all notification creation logic to NotificationController.
(Except the one in CalendarSyncEnabler; which is used only to support
upgrading from pre-froyo and I don't think it's worth refactoring.)
- Note the "password expired/expiring" and "security needed" notifications
aren't changed; they still use extras to store account IDs. This is okay
because these notifications are not per-account.
Bug 4065269
Change-Id: I70737438d2e7c45fd7488a5b0a7105c8568e02f7
We initialize the focus with setNewMessageFocus(), but it's only called
from processSourceMessage() (for EDIT_DRAFT) initFromIntent() (for other
actions, except for "new draft"). We didn't intialize the focus for new
drafts. Let's just get the To field to get the focus by default to
cover this case.
Bug 4048238
Change-Id: I50cd69b8813198c96beab2025576d390520dc6a4
Modified location of the test to processUploadMessage() method. We do this to
prevent creating multiple EmailContent.Message objects.
bug 4096266
Change-Id: Id83d3703283c0cd89a60c6210976093d39fb6934
