Schedule against the whole guest list, and say who cannot be read #183

New Issue

Closed

opened 2026-09-01 17:06:10 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-01 17:06:10 +00:00

Owner

Part 3 of #172, as U1 + B: unknown participants shown as a distinct state, and a scheduling panel inside the event editor. Builds directly on #182.

U1 — nobody is silently dropped

The bar showed the guests it had free/busy for and left out the rest. In a single row that's survivable; as a grid it would be a lie, because a row with nothing in it reads as a diary with nothing in it, and "we cannot see this person's calendar" is the one thing that must not look like "this person is free".

Everyone now gets a row. Those with nothing to read are drawn hatched, with a line under the grid saying how many and why ("1 guest is not on this server, so there is no free/busy to read for them.").

You get a row too, first. Scheduling around the other people and not around yourself is how two things end up at the same time, and the organiser was the one calendar the panel never showed.

B — the panel

Steps backwards and forwards a screenful at a time without touching the event — the "movable forwards & backwards in time" from the report — and offers Back to the event once you've wandered off.
The bars are somewhere to put the event. The pointer readout shows the half-hour it's over, and a click moves the event there keeping its length. Clicking while stepped away moves the event to where you clicked and returns the view to it, so it lands where you were looking instead of jumping.

One bug this surfaced

Your own row came out as unknown. The organiser's calendar is readable by definition — the mismatch is that the directory may not list you under the address your identity sends from (an alias, a login differing from the address). Stalwart answers for your own account under the account's own id, which is now the fallback. The footnote also counted you as a guest; it doesn't any more.

What the live probe settled

Against prod, read-only:

Principal/getAvailability was answered for all 7 directory principals, none of whose calendars are shared with the account. No permission error.
It returns real data — your own principal: 1 event in 60 days → 1 busy period.
A Principal exposes only id, type, name, description, email — no accountId — so there is no handle to ask for anyone's calendar contents. Free/busy isn't the weaker permission; it's the only channel between accounts.

Not settled: the other 6 returned zero over 9 months, consistent both with "empty calendars" and with "empty list instead of an error". Distinguishing needs a second account with an event in it. It doesn't block this PR — the unknown state is what handles the pessimistic case.

Verification

npm run typecheck, npm test (564 pass, 3 new on window stepping) and npm run build green.

By hand against dev:mock, with one directory guest and one external:

rows come out You (busy shown), [email protected] (busy shown), [email protected] (hatched), plus the footnote — and the hatching is unmistakably not an empty bar
‹ › step by day; Back to the event appears when away and disappears on return; stepping back past the start reaches the previous month correctly
clicking 75% along a one-day bar set 6:00 PM – 7:00 PM, duration preserved
stepping forward two days and clicking at 37.5% moved the event to 09/03 9:00–10:00 AM and left the view on Thursday rather than jumping

Screenshot attached in the conversation.

Scope note

The report asked for a separate view. This is the same content inside the editor, which is where the information is wanted while you're picking a time, and it avoids a second surface. If a standalone "when is everyone free next week?" view is still wanted — usable outside event creation — that's a further step and worth its own issue.

Merged 2026-09-01 as coffey-labs/ihasmail@0c1820e2bb

_{Rebuilt from: git history, session transcript.}

Part 3 of #172, as **U1 + B**: unknown participants shown as a distinct state, and a scheduling panel inside the event editor. Builds directly on #182. ## U1 — nobody is silently dropped The bar showed the guests it had free/busy for and left out the rest. In a single row that's survivable; as a grid it would be a lie, because **a row with nothing in it reads as a diary with nothing in it**, and "we cannot see this person's calendar" is the one thing that must not look like "this person is free". Everyone now gets a row. Those with nothing to read are drawn **hatched**, with a line under the grid saying how many and why ("1 guest is not on this server, so there is no free/busy to read for them."). **You get a row too, first.** Scheduling around the other people and not around yourself is how two things end up at the same time, and the organiser was the one calendar the panel never showed. ## B — the panel - **Steps backwards and forwards** a screenful at a time without touching the event — the "movable forwards & backwards in time" from the report — and offers *Back to the event* once you've wandered off. - **The bars are somewhere to put the event.** The pointer readout shows the half-hour it's over, and a click moves the event there keeping its length. Clicking while stepped away moves the event to where you clicked *and* returns the view to it, so it lands where you were looking instead of jumping. ## One bug this surfaced Your own row came out as unknown. The organiser's calendar is readable by definition — the mismatch is that the directory may not list you under the address your identity sends from (an alias, a login differing from the address). Stalwart answers for your own account under the account's own id, which is now the fallback. The footnote also counted you as a guest; it doesn't any more. ## What the live probe settled Against prod, read-only: - `Principal/getAvailability` was **answered for all 7 directory principals**, none of whose calendars are shared with the account. No permission error. - It returns **real data** — your own principal: 1 event in 60 days → 1 busy period. - A `Principal` exposes only `id`, `type`, `name`, `description`, `email` — **no `accountId`** — so there is no handle to ask for anyone's calendar *contents*. Free/busy isn't the weaker permission; it's the only channel between accounts. Not settled: the other 6 returned zero over 9 months, consistent both with "empty calendars" and with "empty list instead of an error". Distinguishing needs a second account with an event in it. It doesn't block this PR — the unknown state is what handles the pessimistic case. ## Verification `npm run typecheck`, `npm test` (564 pass, 3 new on window stepping) and `npm run build` green. By hand against `dev:mock`, with one directory guest and one external: - rows come out **You** (busy shown), **[email protected]** (busy shown), **[email protected]** (hatched), plus the footnote — and the hatching is unmistakably not an empty bar - ‹ › step by day; *Back to the event* appears when away and disappears on return; stepping back past the start reaches the previous month correctly - clicking 75% along a one-day bar set 6:00 PM – 7:00 PM, duration preserved - stepping forward two days and clicking at 37.5% moved the event to 09/03 9:00–10:00 AM **and left the view on Thursday** rather than jumping Screenshot attached in the conversation. ## Scope note The report asked for a *separate* view. This is the same content inside the editor, which is where the information is wanted while you're picking a time, and it avoids a second surface. If a standalone "when is everyone free next week?" view is still wanted — usable outside event creation — that's a further step and worth its own issue. **Merged** 2026-09-01 as coffey-labs/ihasmail@0c1820e2bbda <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#183