Calendar: skip events on re-import when their UID is already in the calendar #222

New Issue

Closed

opened 2026-09-02 15:46:11 +00:00 by jcoffey-dev · 1 comment

jcoffey-dev commented

2026-09-02 15:46:11 +00:00

Owner

Split out of #173 so it stops living in a comment thread.

Importing the same .ics twice currently creates second copies of every event. The import keeps the file's own UID where there is one (and invents one only where there isn't), so the information needed to match is already there — nothing looks for it.

The reporter has decided the behaviour (#173 comment):

Both of us would prefer duplicate checks on UIDs if UID present in event.

His colleague hit the duplication during testing and was confused by it, which is the more telling half.

What this means

An event carrying a UID that a calendar already holds is skipped, not re-created.
An event with no UID is imported as it is today — there is nothing to match it on, and inventing a match would be a guess.
The count reported back should distinguish the two, so "Imported 40 events" doesn't quietly mean "and skipped 200".

Notes

Matching is per-calendar rather than global: the same event legitimately exists in two calendars, and that is what a UID means across them.

Worth deciding alongside: whether a re-imported event whose UID matches should update the existing one rather than be skipped, since re-importing an updated export is a plausible reason to do this at all. The reporter asked for skip; update is the larger behaviour and nobody has asked for it.

The contacts half of this is #223 — related, but not the same decision, because LDIF entries have no reliable identity.

_{Rebuilt from: session transcript.}

Split out of #173 so it stops living in a comment thread. Importing the same `.ics` twice currently creates second copies of every event. The import keeps the file's own UID where there is one (and invents one only where there isn't), so the information needed to match is already there — nothing looks for it. **The reporter has decided the behaviour** ([#173 comment](https://github.com/Coffey-Labs/ihasmail/issues/173#issuecomment-5510955196)): > Both of us would prefer duplicate checks on UIDs if UID present in event. His colleague hit the duplication during testing and was confused by it, which is the more telling half. ## What this means - An event carrying a UID that a calendar already holds is **skipped**, not re-created. - An event with no UID is imported as it is today — there is nothing to match it on, and inventing a match would be a guess. - The count reported back should distinguish the two, so "Imported 40 events" doesn't quietly mean "and skipped 200". ## Notes Matching is per-calendar rather than global: the same event legitimately exists in two calendars, and that is what a UID means across them. Worth deciding alongside: whether a re-imported event whose UID matches should *update* the existing one rather than be skipped, since re-importing an updated export is a plausible reason to do this at all. The reporter asked for skip; update is the larger behaviour and nobody has asked for it. The contacts half of this is #223 — related, but not the same decision, because LDIF entries have no reliable identity. <sub>Rebuilt from: session transcript.</sub>

jcoffey-dev commented

2026-09-02 15:58:44 +00:00

Author

Owner

Shipped in #225, live as 2026.9.2+pr225.

Skip on a UID the calendar already holds; import what arrives without one; match per calendar, so the same event in a second calendar is not a duplicate. Counts are reported separately so a mostly-already-here import doesn't read as a failure.

The open sub-question from the description stands and is not done: whether a matching UID should update the existing event rather than be skipped. Asked on #173. If the answer is yes it's a new issue, not a reopening of this one.

Shipped in #225, live as `2026.9.2+pr225`. Skip on a UID the calendar already holds; import what arrives without one; match per calendar, so the same event in a second calendar is not a duplicate. Counts are reported separately so a mostly-already-here import doesn't read as a failure. The open sub-question from the description stands and is *not* done: whether a matching UID should **update** the existing event rather than be skipped. Asked on #173. If the answer is yes it's a new issue, not a reopening of this one.

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#222