Skip to content

feature: Link notes to a mail and show them in the mail view - #101

Open
r4nc0r wants to merge 6 commits into
grommunio:masterfrom
r4nc0r:feature/notes-linked-to-mail
Open

feature: Link notes to a mail and show them in the mail view#101
r4nc0r wants to merge 6 commits into
grommunio:masterfrom
r4nc0r:feature/notes-linked-to-mail

Conversation

@r4nc0r

@r4nc0r r4nc0r commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Lets a sticky note be linked to a mail and shown in the mail header, so that a mail can be annotated without touching it.

The note holds the mail's PR_INTERNET_MESSAGE_ID in a note_link_id named property, and is created in the Notes folder of the store the mail lives in rather than the user's own, so everyone with access to that mailbox sees the same notes. Nothing is written to the mail:

  • the message id survives the mail being moved between folders, which an entryid does not, and needs no id to be generated or handed out;
  • there is no two-phase save, so two people annotating one mail cannot conflict;
  • read-only access to the Inbox plus create rights on Notes is enough, which is the least a mailbox can be shared with and still be annotated.

A mail with no PR_INTERNET_MESSAGE_ID cannot be annotated. Those are not received mail, which is what this is for.

The panel hangs off the previewpanel.toolbar.detaillinks insertion point next to the calendar's meeting info, so it appears in the preview panel, the separate window and on conversation cards alike. It renders nothing for a mail without notes. Note bodies are plain text and are escaped before display. The note list now also fetches PR_BODY so a note can be read where it is shown rather than only after opening it; sticky notes are small and live in a single folder, so unlike the mail list this does not meaningfully grow the request.

Notes are added from the mail context menu. The note dialog names the mail a note is on and opens it; for that direction the note also records the mail's entryid, parent entryid and subject. A mail is identified by all of its id properties together, so all of them are kept: a record built from a partial id is compared against any record already loaded for the same mail while it opens, and that comparison then dereferences null, leaving a tab that never finishes loading. A record already loaded for the mail is reused in preference to building a second one.

The named properties are keyed by string rather than dispid, since the id space is shared and a number could collide.

The property cache fix

The first commit fixes a bug in Properties that this feature cannot work on a shared mailbox without, kept separate so it can be reviewed and reverted on its own.

Properties caches resolved named property ids under PR_MAPPING_SIGNATURE, so that each store gets its own set. gromox reports an all-zero PR_MAPPING_SIGNATURE for every store while still allocating named property ids per store, so every store shares one cache entry and the first store to resolve a name hands its ids to all the others. getStoreMappingSignature() now falls back to the store entryid, which does identify the store.

The key also has to be recomputed when the active store changes. Init() only does that while $init is false, and $init is reset once per request rather than once per module, so in a request touching several stores the second module onwards kept answering for the first module's store. setStore() now clears $init. Either change alone is insufficient.

This is not noticeable on the named properties in the tree today, because they happen to resolve to the same ids in every store: they are allocated in the same order in each freshly created store. It becomes noticeable as soon as a named property is introduced that stores allocate at different times, since each store then has its own allocation history — note_link_id resolved to 0x82C9 in one store and 0x82C3 in another, and the cache handed the first store's id to both.

Testing

Tested against a shared mailbox with two users: one with read-only access to the other's Inbox and write access to its Notes folder, confirming the annotation is written into the shared store and is visible to the mailbox owner on the same mail, and that the mail's PR_BODY and PR_LAST_MODIFICATION_TIME are unchanged.

@r4nc0r

r4nc0r commented Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

do you have any feedback on this?

@gromandreas

Copy link
Copy Markdown
Member

do you have any feedback on this?

I'm going through the github PRs today, so I'll comment if I have some feedback.

@gromandreas

Copy link
Copy Markdown
Member

First I have some general notes:

  • It's called "add note" which is not consistent with "create appointment" and "create task". I prefer if "create note" is used.
  • It's placed it between "create appointment" and "create task" which is not consistent with the top bar navigation (email -> calendar -> contacts -> tasks -> notes). I prefer to place it under "create task".
  • I'm not quite happy with the icon. The other icons have the action symbol ("+"/arrow/gear sign) on the right side, while the "add note" icon has it on the top left.
  • A note opened from the Notes folder has a limited height. Before it would occupy the whole height of a tab, this is the expected behavior. (Observed with Firefox on Ubuntu and with Chrome both on Ubuntu and Windows)
  • Only the first 5 lines of a note in an email are visible. The 6th and following lines of a note are hidden and the note is not scrollable. (Observed with Firefox on Ubuntu and with Chrome both on Ubuntu and Windows)

@r4nc0r

r4nc0r commented Jul 29, 2026

Copy link
Copy Markdown
Contributor Author

all done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants