EWS/OWA: Dependent/main accounts

[benbucksch]

Situation

When the user sets up an Office365, or Google, or Mustang account, the mail account also comes with address book sync, calendar sync, file sharing, and video conference. We are creating corresponding "accounts" in Mustang, one for each address book, one for each calendar etc.

Problem

Their login is directly dependent on the login of the main mail account. I.e. if I didn't log in to the mail account, then saving a contact to the server will fail.

Solution

Link

Create an explicit "dependent" and "main" account link. I.e. the address book has a "mainAccount" property which points to the mail account. And the mail account has a "dependentAccounts" array, which points to the address books, calendars, file sharing, video conference accounts.

isLoggedIn

The address book's isLoggedIn will simply return this.mainAccount.isLoggedIn. For that to work, the address book needs to subscribe to the main account changes on load (in the moment when the mainAccount property is set), so that listeners to the address book isLoggedIn state are updated as soon as the mail account login state changes.

Login

Likewise, the address book's login() function will simply delegate to this.mainAccount.login().

When a contact needs to be saved to the server, and the main account is not logged in, the dependent account needs to trigger the login. Whether an interactive login is requested depends on whether the user himself started the modification directly, or whether it's a background process.

Save link on disk

The link needs to be saved on disk, and restored on load.

[NeilRashbrook]

isLoggedIn is a getter, not a state, so there are no notifications for it.

[benbucksch]

Notifications are on the object level, not property level. The notifications happen for any object property which has the notifyChangedProperty decorator on it. So, if the isLoggedIn is based on a property of the object, the observer should be called.

[NeilRashbrook]

isLoggedIn isn't a property (as I already said) so it wouldn't have the notifyChangedProperty decorator on it either. But even if it had the notifyChangedAccessor decorator, you wouldn't be able to change it, as there's no setter for it to override (the call to invoke the setter would throw; ideally notifyChangedAccessor would assert decorator.set exists so that you would notice your mistake earlier).

[benbucksch]

I know. But:

• OWAAccount has hasLoggedIn (which was missing the notifyChangedProperty, but I added it recently). Likewise,
• IMAPAccount has the _connection property, which will be set on login and cleared on known connection failure.
• Same for fatalError.
• For EWSAccount with OAuth, we are actively subscribing to the this.oAuth2 object when it's being set, so if this.oAuth2.isLoggedIn changes, its observers will fire, which then fires the observers of EWSAccount, which tells observers to update isLoggedIn.
• All else failing, you can manually call notifyObservers() (see Observable). But it's typically better to make a property this._isLoggedIn or connection or other, with notifyChangedProperty decorator, and set that property on login and failure.

In other words, if the login state changes and the observers don't fire, that's an implementation error of the account. The account must ensure that the observers fire in this case.

[benbucksch]

Here, in this case, the dependent account will be notified of login changes of the main account, because the following part of Solution takes care of it: "For that to work, the address book needs to subscribe to the main account changes on load (in the moment when the mainAccount property is set), so that listeners to the address book isLoggedIn state are updated as soon as the mail account login state changes."