Closed Bug 892518 Opened 11 years ago Closed 11 years ago

[User Story] Ability to Change Sync Interval

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:koi+)

VERIFIED FIXED
1.2 FC (16sep)
blocking-b2g koi+

People

(Reporter: pdol, Assigned: jrburke)

References

Details

(Keywords: feature, Whiteboard: [ucid:Productivity3, FT:Productivity, KOI:P1])

Attachments

(1 file, 2 obsolete files)

User Story:

As a user, I would like to be able to specify the synchronization frequency when setting up an email account and from within the email settings to chose how often synchronization occurs to help save on battery life and so that I am notified of emails in a timely fashion.


Acceptance Criteria:

1. I can change the Email sync frequency setting per account from the Email settings
2. I can chose an Email sync frequency when setting up an Email account
3. I can chose a synchronization frequency between the following intervals: never, 5 minutes, 10 minutes, 15 minutes, 30 minutes, 1 hour
4. The default sync frequency setting is never
5. In addition to checking for new email when I open the email app, my device checks the server for new email messages at the frequency specified, even when the email app is not open, notifying me if new emails have arrived
Component: Gaia::E-Mail → Gaia::Clock
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/53237797
Component: Gaia::Clock → Gaia::E-Mail
Dylan Oliver added a comment in Pivotal Tracker:   
   
Comment!
Dylan Oliver changed story state to started in Pivotal Tracker
Dylan Oliver changed story state to finished in Pivotal Tracker
Dylan Oliver changed story state to delivered in Pivotal Tracker
Dylan Oliver changed story state to rejected and added a comment in Pivotal Tracker:   
   
NO good
Candice Serran changed story state to started in Pivotal Tracker
Dylan Oliver changed story state to unstarted in Pivotal Tracker
blocking-b2g: koi? → koi+
Whiteboard: [ucid:Productivity3] → [ucid:Productivity3, FT:Productivity, KOI-P1]
Assignee: nobody → gaye
Assignee: gaye → jrburke
There is now a zip with the changes for this ticket, it can be found in bug 892519:
https://bugzilla.mozilla.org/attachment.cgi?id=794115

Deviations in the zip as compared to the UX spec:

_03 Account options:

* Should there be a back button on the second screen? The account is already
set up, and we do not have a reasonable mechanism to go "back" in this case, so I left out the back button.

* Newly added accounts are automatically set as the default account, and the way the "set as default email" works is that the user has to select the unchecked checkbox for the account they want as the default. There is not a concept in the back end storage of being able to "unselect" an acccount as default as the rules for then deciding what other account to select are vague, or at least not defined as of today. So I left the "Set as default e-mail" out of this screen. If it is desired, then we need to have a larger discussion around the rules for selecting a default, and I would prefer to track that as a separate bug since it goes beyond what is needed for sync interval.

Account Settings:

* Right now, I kept the pre-existing checkbox style for "set as default e-mail", which is a squarish thing. However, the "Display notifications for new messages" is a toggle switch. I'm not sure if there is desire to unify those. One difference in behavior is that "set as default e-mail" can only be set to checked. Once checked, then it cannot be unchecked: the user goes to the other account they want as default to select it to change the default. If a different behavior is wanted for that default e-mail checkbox that is different than what is done today, I prefer to use a separate bug to track that.

General question:

* When showing the Inbox, should the UI show that it is doing a periodic sync (the background sync ) by spinning the circular sync arrow in the lower left of the message list screen? Right now the app does not do that.
Flags: needinfo?(firefoxos-ux-bugzilla)
There is a new app zip for this ticket:

https://bugzilla.mozilla.org/show_bug.cgi?id=892519#c14
Flagging Rob and Jacqueline as this is about email sync specifically.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
Flags: needinfo?(firefoxos-ux-bugzilla)
Whiteboard: [ucid:Productivity3, FT:Productivity, KOI-P1] → [ucid:Productivity3, FT:Productivity, KOI:P1]
Flags: in-moztrap+
Target Milestone: --- → 1.2 FC (16sep)
Comment on attachment 803130 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/249

In gelam: while doing the integration test for bug 892518, tracing through the logic, I found a small issue where if no alarms are found, the exit early inside mozAlarms.getAll() onsuccess if no alarms would mean not sending the 'syncEnsured' message back to the worker, which means the cronsync may not send future ensureSync checks since it blocks further calls until it gets a response from cronsync-main's ensureSync.

This change will be rolled up into the gaia changeset for 892518.
Attachment #803130 - Flags: review?(bugmail)
Pointer to Github pull-request
Comment on attachment 803137 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/12128

main-frame-setup change will be reviewed in the gelam pull request, and is minor fix:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/249

The code that provides this basic feature was already delivered in bug 892519. This changeset is mainly about the integration test addition.

This changeset also introduces some new plumbing for email integration tests. In the email/test/marionette directory:

* email.js was moved to lib/email.js. @lightsofapollo suggested moving all the helper scripts into libs and leave tests in the marionette directory.
* lib/email_data.js: provides wrappers over data operations sent to the email app's content space.
* lib/debug.js formalizes the helper function instrumentation that existed earlier for just lib/email.js
* lib/mocks/mock_navigator_mozalarms.js: a mock for mozAlarms to test correct setting of mozAlarms from the app code.
* lib/email.js: in _tapSelector, a waitForElement was added to make sure the tap target is visible and available for clicking. This seems to fix the intermittent waitForTransitionEnd failure currently seen in the tests. At least I think so. I ran all email unit tests 7 times in a row. That resulted in 8 tests running, for a total of 56 attempts at an intermittent failure. Previously, the failure would have happened before reaching 56 runs.

Asking :lightsofapollo for review of the tests. :asuth will review the main-frame-setup change in the gelam pull request.
Attachment #803137 - Flags: review?(jlal)
Comment on attachment 803130 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/249

Closing the gelam pull request: this change was not necessary: mozAlarms always returns an array, just could be empty. I needed this because an earlier version of my mock him for mozAlarms in the integration test was not sending the right empty array value. but does the right thing now.
Attachment #803130 - Attachment is obsolete: true
Attachment #803130 - Flags: review?(bugmail)
Fixed in the changeset that fixed bug 892519. The pull request on this bug will be used as the basis for the integration test bundle in bug 915639 .

Committed to Gaia master:
https://github.com/mozilla-b2g/gaia/commit/2d240c619e54801dd5a4290adb14b5529133ef36

Pull request:
https://github.com/mozilla-b2g/gaia/pull/11499

Committed to GELAM:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/25ba2035b2100c5e8da28265f9e350bc2f1304b2

Pull request:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/232
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #803137 - Attachment is obsolete: true
Attachment #803137 - Flags: review?(jlal)
(In reply to James Burke [:jrburke] from comment #11)
As per James comment 11 I opened separate bug to track/discuss issue of setting account as a default during Setup process. Bug 916308 "User does not have an option setting Email account as a "Default" during email Setup" https://bugzilla.mozilla.org/show_bug.cgi?id=916308

> * Newly added accounts are automatically set as the default account, and the
> way the "set as default email" works is that the user has to select the
> unchecked checkbox for the account they want as the default. There is not a
> concept in the back end storage of being able to "unselect" an account as
> default as the rules for then deciding what other account to select are
> vague, or at least not defined as of today. So I left the "Set as default
> e-mail" out of this screen. If it is desired, then we need to have a larger
> discussion around the rules for selecting a default, and I would prefer to
> track that as a separate bug since it goes beyond what is needed for sync
> interval.
Blocks: 916308
Verified Fixed: User can now select a periodic sync interval for Email App.

Environmental Variables
Device: Buri v1.2 COM RIL
Build ID: 20131105004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/3ba912717904
Gaia: be4ea00a50236b10eb0a03232a28ffd0048e0cb8
Platform Version: 26.0
RIL Version: 01.01.00.019.281 
Firmware Version: US_20131015
Status: RESOLVED → VERIFIED
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: