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

Implement WebDAV ACL operations on calendars (RFC 3744)

Đang mở
  • Có gì không ổn?
#699 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
3-5 ngày
Mức phù hợp với người mới
35/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 caldav/elements/dav.py and §1.1 of docs/design/FEATURE_COMPLETE_ROADMAP.md, then inspect the existing principal_property_search implementation and compatibility hints. The issue proposes phased work: expose ACL-related properties, resolve principals, and support ACL writes with server compatibility checks. Done means the selected phases are implemented and covered by tests that account for servers without ACL support.

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 work on ways to share access to calendars for other users. The established WebDAV standard for this is RFC 3744, unfortunately it's not supported by a lot of servers. 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, the draft proposal has a separate issue #701.

The estimate for this issue is 40 hours.

The text below is AI-generated.

⚠️ This text is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "Do we have any issue on RFC 3744 and ACL-operations? If not, create a feature issue for doing ACL-operations on calendars."

The library has no support for access control today: there is no acl() method, no Acl / Privilege / CurrentUserPrivilegeSet elements (caldav/elements/dav.py has only Owner and CurrentUserPrincipal), and no compatibility hints for ACL. docs/design/FEATURE_COMPLETE_ROADMAP.md §1.1 scopes this as a high-priority, 40–60h item and notes "Related issues: None currently open" — this issue is that missing tracking issue.

Closest prior art is #202 ("Is it possible to share calendars with another user using caldav?"), closed in 2022 with "there is no support for granting access rights through the CalDAV protocol". That is still true, and it is the user-facing need this would eventually serve.

Suggested scope, in order of value-per-effort

Phase 1 — read the ACL (cheap, widely supported, useful on its own)

  • DAV:current-user-privilege-set via PROPFIND — "what may I do with this calendar?" This alone answers a common practical question (is this calendar read-only for me?) and needs no ACL method support on the server.
  • DAV:owner is already an element but is not exposed on collections.
  • Read DAV:acl and parse it into something inspectable (ACE list: principal, grant/deny, privileges, protected/inherited flags).
  • DAV:supported-privilege-set so callers can discover what a server actually offers.

Phase 2 — principal resolution

  • Resolve a principal from an email address / user name to a principal URL, needed before any ACE can be written. principal_property_search (RFC 3744 §9.4) already exists in the codebase for this and could be reused.
  • DAV:acl-principal-prop-set REPORT to enumerate who has access.

Phase 3 — write the ACL (the risky part)

  • The ACL HTTP method itself, with the standard privileges DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, plus CALDAV:read-free-busy (RFC 4791 §6.1).
  • Convenience helpers for the common patterns: grant read-only, grant read-write, revoke.
  • Error handling for the RFC 3744 §7.1.1 precondition-failure bodies (DAV:not-supported-privilege, DAV:no-protected-ace-conflict, DAV:recognized-principal, …) — servers signal why an ACL was rejected in a machine-readable way, and that should surface as distinct exceptions rather than a generic error.

Compatibility

ACL support is very uneven, so this needs compatibility hints and server-tester checks from the start rather than bolted on afterwards:

  • Something like acl.read, acl.current-user-privilege-set and acl.write, so the integration tests can skip rather than fail.
  • Radicale has no ACL method; DAViCal, Cyrus and Bedework have varying degrees of support; Google and Nextcloud do sharing through their own non-standard APIs.

Why this may not be worth doing (or not doing first)

Being honest about the downside: RFC 3744 is one of the least uniformly implemented parts of the WebDAV stack. What users actually ask for is calendar sharing (#202), and on the servers most people use, sharing is not done through RFC 3744 — it is done through draft-pot-caldav-sharing (roadmap §3.2) or a server-specific API. So a fully generic ACL implementation risks being a large amount of work that raises "not supported" on the majority of real deployments.

Mitigation is the phasing above: phase 1 is small, broadly supported, and independently useful even if phases 2–3 are never finished.

RFC refs: https://datatracker.ietf.org/doc/html/rfc3744 and https://datatracker.ietf.org/doc/html/rfc4791#section-6.1

⚠️ 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
1 ngày 2 giờ
Pull request đã merge (30 ngày)
41

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.