Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#701 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
api, backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
412
Fork
113
Merge trung bình
22 giờ 15 phút
Pull request đã merge (30 ngày)
44

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của python-caldav/caldav

Tất cả issue của python-caldav/caldav

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.