Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Implement WebDAV ACL operations on calendars (RFC 3744)

Aperta
  • Qualcosa non va?
#699 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
api, backend-api-design

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
412
Fork
113
Merge medio
1g 14h
PR unite (30g)
26

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di python-caldav/caldav

Tutte le issue di python-caldav/caldav

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.