JMAP: session object always returns hasDataFor: [ mail ] shared accounts even if only addressbook or calendar shared

[robmueller]

If a user Y shares only their address book with another user X, then when you fetch the JMAP session for use X, you get:

{
  "X": {
   ...
  },
  "Y": {
    "name": "Y",
    "isPrimary": false,
    "isReadOnly": false,
    "hasDataFor": ["mail"]
  }
}

The hasDataFor field should just be ["contacts"].

In general, you need to look at the types of all shared mailboxes and generate an appropriate hasDataFor set based on that (e.g. some combination of "mail", "contacts", "calendars" depending on which folder types have been shared).

[rsto]

That should be simple to do.

The way why this is done as-is: neither the JMAP calendar nor contacts spec define what to add in the hasDataFor property. So, it seemed OK to assume that just actual JMAP mail clients might care about what's in the hasDataFor property.

I'll add this this soon, but the spec for contacts and calendars might need to be updated as well.

[robmueller]

Yes right, this hasn't been standardised yet, however it's really useful to know what data types cyrus is making available via ACL sharing (so you know if you can do Mailbox/get, Contact/get and/or Calendar/get on a particular accountId), so having hasDataFor contain "mail", "contacts" and "calendars" as possible data types is certainly useful for clients.

These will hopefully eventually be standardised one day.

[rsto]

I've already pushed this to master with the entries being mail, contact and calendar (no plural). Fine with you?

[robmueller]

Talking with @neilj we think that maybe these should be the urn's, so:

• urn:ietf:params:jmap:mail
• urn:ietf:params:jmap:contacts
• urn:ietf:params:jmap:calendars

That seems reasonable to me. Those last two are not official yet obviously, but they're neil's proposed ones.