Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Support calendar sharing (draft-pot-caldav-sharing)

未关闭
  • 哪里不对？
#701 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
python
领域
api, backend-api-design

调研方向

Start with the draft-pot-caldav-sharing spec and the roadmap entry in docs/design/FEATURE_COMPLETE_ROADMAP.md, then probe the Docker test servers as the issue suggests. This issue is research and scope-setting before implementation: document what the servers support and decide whether sharing, ACLs, or both should be pursued; the implementation tasks are broad and no files or tests are named.

由索引模型根据 Issue 内容生成。

描述

enhancement roadmap

We should consider supporting draft-pot-caldav-sharing as it's supported by some servers. Some AI-generated information below the line.

⚠️ This issue is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "We need an issue for 3.2 (which is related to 1.1)"

Tracking issue for section 3.2 of docs/design/FEATURE_COMPLETE_ROADMAP.md. Sibling of #699 (RFC 3744 ACL), which says: "There is an expired draft-pot-caldav-sharing that may be supported by some servers - the scope of this issue is to ensure support for RFC 3744, but eventually research should be done on the draft proposal as well." This is that issue.

Relationship to #699

The two are competing answers to the same user request — "let my colleague see my calendar", asked in #202 and closed in 2022 with "there is no support for granting access rights through the CalDAV protocol".

  • #699 / RFC 3744 is the real standard, and is thinly implemented.
  • This / draft-pot-caldav-sharing is an expired individual draft, and is what the servers people actually use have implemented — Apple Calendar Server, and the SabreDAV family (Baikal, Nextcloud) through the http://calendarserver.org/ns/ namespace.

They are not redundant: ACL grants privileges on a collection, sharing sends an invitation that the sharee accepts or declines, and gives them their own bound copy with its own alarms. A user asking to "share a calendar" almost always wants the second one.

Suggested decision, to be made in one place rather than twice: research this draft first, since it is cheap to probe against the docker test servers and tells us what the ecosystem actually does. Then decide whether ACL, sharing, or both is worth implementing.

Current state

Nothing. No calendarserver.org namespace in caldav/elements/, no sharing properties, no notification-collection support.

One naming hazard worth flagging up front: accept_invite(), decline_invite() and tentatively_accept_invite() already exist on CalendarObjectResource and mean iTIP event invitations (RFC 6638). Sharing invitations are a different concept on a different object. Whatever API this gets must not be confusable with the existing methods — calendar.accept_share_invite() or similar, never an overload of accept_invite.

Tasks

  • Research: read the draft, and probe what the docker test servers actually implement
  • Elements for the http://calendarserver.org/ns/ namespace — invite, share, invite-reply, shared-owner, access levels
  • Detect that a calendar is shared, and whether we are the owner or a sharee
  • Enumerate calendars shared with the user
  • Share a calendar with another user (read / read-write)
  • Accept and decline share invitations, via the notification collection
  • Remove share access
  • Per-user calendar data — separate alarms per sharee
  • Compatibility hints, so tests skip rather than fail
  • Documentation, since this is the answer to a FAQ (#202)

Caveats

  • It is an expired draft, never standardised. Implementing it means tracking whatever each server actually does, not a spec.
  • Google and Microsoft do sharing through their own APIs and are out of reach either way.
  • Whether the notification-collection dance can be made to feel reasonable in a synchronous client library is an open question.

Spec: https://datatracker.ietf.org/doc/html/draft-pot-caldav-sharing

⚠️ AI-generated by Claude Opus 5 via Claude Code on behalf of tobixen.

主要语言
Python
星标
412
派生
113
平均合并
11 小时 3 分钟
30 天内合并 PR
70

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

python-caldav/caldav 的其他 Issue

查看 python-caldav/caldav 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。