Contacts: View Details

[kulmann]

Initial Checklist

• I understand this is a user story and questions should be posted in the Community Discussions
• I searched issues and couldn’t find anything (or linked relevant results below)

User Story

• As a user, I want to view details of a contact so that I can find more information than just name and email from the list view.

User Value

Contacts MVP

Acceptance Criteria

• contact list has a three dots button per entry
• three dots button shows "Details" as context menu entry
• clicking the "Details" context menu entry or the contact name triggers showing the Details of the contact
• details view shows all available data for the contact in collapsible panels, like in the attached mockup
• on mobile: details show in a bottom drawer
• on desktop: details show in the right sidebar (similar to user details in the admin settings app)

NOT part of this story:

• don't show the "write email" button
• don't show "Edit" or "Delete" buttons, yet
• no tags
• no attached images/files

[kulmann]

@pbleser-oc how does stalwart handle labels for fields, e.g. "Work email" and "Personal email" or even a custom label for an email address?

[pbleser-oc]

@pbleser-oc how does stalwart handle labels for fields, e.g. "Work email" and "Personal email" or even a custom label for an email address?

Those are defined in RFC 9553 (JSContact) for each type of object, using the "context" attribute which is a map where the key defines the context, and true as its value.

There are always some pre-defined "standard" contexts (usually "work" and "private") but proprietary/custom ones can be used as well.

For example, for emails: https://www.rfc-editor.org/rfc/rfc9553.html#prop-contexts

{
  "emails": {
    "e1": {
      "address": "jdoe@example.com",
      "contexts": { "home": true, "private": true }
    },
    "e2": {
      "address": "jane.doe@acme.com",
      "contexts": { "work": true }
    }
}

(e1 and e2 are just opaque identifiers here, to be able to address them by API references)

Those labels (home, private, work, ...) are just opaque strings that need to be displayed and localized by the UI.

[pbleser-oc]

The example in the screenshot above can be represented as JSContact (JMAP) as follows:

{
  "id": "loTh8ahmubei",
  "addressBookIds": {
    "79047052-ae0e-4299-8860-5bff1a139f3d": true
  },
  "@type": "Card",
  "version": "1.0",
  "created": "2025-07-09T07:12:28+02:00",
  "kind": "individual",
  "language": "en-GB",
  "prodId": "OpenCloud Groupware 1.0",
  "relatedTo": {
    "096fc269-ffc4-4f2f-978f-5bd1bb0962d5": {
      "relation": {
        "manager": true
      }
    }
  },
  "uid": "ffcb3f80-8334-46ff-882b-fcb7dff49204",
  "updated": "2025-07-10T09:58:01+02:00",
  "name": {
    "@type": "Name",
    "components": [
      {
        "value": "Bessie",
        "kind": "given"
      },
      {
        "value": "Cooper",
        "kind": "surname"
      }
    ],
    "isOrdered": true,
    "defaultSeparator": " "
  },
  "nicknames": {
    "soacaivie5Po": {
      "name": "Bess",
      "contexts": {
        "private": true,
        "work": true
      }
    }
  },
  "organizations": {
    "oocooXeiya9L": {
      "name": "Organization's name",
      "units": [
        {
          "name": "Department"
        }
      ]
    }
  },
  "speakToAs": {
    "grammaticalGender": "feminine"
  },
  "titles": {
    "Pahd2Azeedai": {
      "name": "Role in project/company",
      "kind": "role",
      "organizationId": "oocooXeiya9L"
    },
    "yohshohTh4so": {
      "name": "Job title",
      "kind": "title",
      "organizationId": "oocooXeiya9L"
    }
  },
  "emails": {
    "bueVua3Eith8": {
      "address": "bessiecooper@mail.com",
      "contexts": {
        "home": true
      }
    },
    "foo5Isheel2t": {
      "address": "bessiecooper@mail.com",
      "contexts": {
        "private": true,
        "work": true
      }
    }
  },
  "onlineServices": {
    "soo6fohsh9Ae": {
      "service": "LinkedIn",
      "user": "@bessiecooper",
      "contexts": {
        "work": true
      }
    }
  },
  "phones": {
    "aish5bahQu4t": {
      "number": "+1-555-123-4567",
      "contexts": {
        "work": true
      }
    },
    "oopeej8ev9Oi": {
      "number": "+1-555-123-1234",
      "contexts": {
        "home": true,
        "private": true
      }
    }
  },
  "preferredLanguages": {
    "Aelujee9moi1": {
      "language": "en-US",
      "contexts": {
        "private": true,
        "work": true
      },
      "pref": 1
    },
    "SheFai0Aishi": {
      "language": "de-DE",
      "contexts": {
        "private": true
      },
      "pref": 2
    }
  },
  "addresses": {
    "pieF3Uc2eg9M": {
      "components": [
        {
          "value": "2972",
          "kind": "number"
        },
        {
          "value": "Westheimer Rd.",
          "kind": "name"
        },
        {
          "value": "Santa Ana",
          "kind": "locality"
        },
        {
          "value": "Illinois",
          "kind": "region"
        },
        {
          "value": "85486",
          "kind": "postcode"
        }
      ],
      "countryCode": "USA",
      "contexts": {
        "private": true,
        "work": true
      }
    }
  },
  "media": {
    "Zae0ahPho6ae": {
      "kind": "logo",
      "uri": "https://acme.com/logo.jpg",
      "mediaType": "image/jpeg",
      "contexts": {
        "work": true
      }
    },
    "iegh7veeJ9ta": {
      "kind": "photo",
      "mediaType": "image/png",
      "contexts": {
        "private": true,
        "work": true
      },
      "blobId": "ieP4huzohv8gexahzeizei0che2keedu"
    }
  },
  "anniversaries": {
    "at4Jaig2TeeT": {
      "kind": "birth",
      "date": {
        "@type": "PartialDate",
        "year": 1980,
        "month": 1,
        "day": 22
      }
    }
  },
  "keywords": {
    "important": true,
    "sales": true
  },
  "notes": {
    "beecaeViShu6": {
      "note": "Bess likes chocolate",
      "created": "2025-07-09T07:12:28+02:00",
      "author": {
        "name": "Stina"
      }
    }
  }
}

[pbleser-oc]

It is worth noticing though that JSCalendar is quite a bit more flexible than that.

We should decide whether the representation in the UI should either be close to JSCalendar's capabilities/format/attributes, or whether to rather have a "UI first" approach where we focus on usability, what other products are doing (user expectation management, so to speak).

With "close to JSCalendar", I mean e.g. to not do it like this:

• Addresses
  • Work: 2972 Westheimer Rd...
  • Home: 2972 Westheimer Rd...

but rather like this:

• Addresses
  • 2972 Westheimer Rd... [work, home]

Email-Addresses and most everything else has a context attribute (with values like private, work, billing, delivery, ...).

[pbleser-oc]

Note that there is no "Gender" attribute in JSContact.

Instead, there is the speakToAs attribute with a grammaticalGender attribute that has an enum list of possible values (animate, common, feminine, inanimate, masculine, neuter) as well as a set of 0-n pronouns, which are free text.

Those can then also be translated using the localizations attribute, as for most things in a JSCalendar ContactCard

Example:

{
  "speakToAs": {
    "pronouns": {
      "p1": {
         "pronouns": "she/her",
         "contexts": { "work": true, "private": true },
         "pref": 1
      },
      "p2": {
          "pronouns": "they/them",
          "contexts": {"work": true },
          "pref": 10
      }
    }
  },
  "localizations": {
    "de-DE": {
      "speakToAs": {
        "pronouns":  {
          "p1": {"pronouns": "sie/sie"}
        }
      },
    },
    "fr-FR": {
      "speakToAs": {
        "pronouns":  {
          "p1": {"pronouns": "elle/son"}
        }
      }
    }
  }
}

[pbleser-oc]

Addresses also have a much more detailed representation in the JSContact format.

Instead of just being a free text string, they are composed of a list of components that each have a specific "kind" to identify the part of the address.

The example above would be like this instead:

{
  "addresses": {
    "pieF3Uc2eg9M": {
      "components": [
        {"value": "2972", "kind": "number"},
        {"value": "Westheimer Rd.", "kind": "name"},
        {"value": "Santa Ana", "kind": "locality"},
        {"value": "Illinois", "kind": "region"},
        {"value": "85486", "kind": "postcode"}
      ],
      "countryCode": "USA"
  }
}

Alternatively, though, it can also be stored as a free text string, like this:

{
  "addresses": {
    "pieF3Uc2eg9M": {
      "full": "2972 Westheimer Rd. Santa Ana, Illinois 85486",
      "countryCode": "USA"
    }
}

We will have to decide on the level of precision we want to provide the users with, vs the degree of complexity of the UI. It smells like having a "simple" vs "advanced"/"detailed" mode.

As a side note, addresses also have a coordinates attribute in which a geo: URI may be stored.