Skip to main content
Petanque Life

Product Roadmap

Transparency is a core value. See exactly what we have shipped, what we are working on, and what is coming next — and vote on what matters most to you.

3106
Shipped
0
In Progress
36
Planned
Show:

Shipped

3106
01 102 features

Federation & Governance

  • Standalone tenant per federation (national, continental, world)
  • Tenant creation, configuration, branding
  • Federation profile pages (logo, address, contacts, statutes, history)
  • +99 more
02 194 features

Identity & Access Management

  • Self-registration with email/phone verification
  • OAuth2 social login (Google, Microsoft, GitHub)
  • Player profile (name, DOB, nationality, photo, playing position)
  • +191 more
03 124 features

Membership & Licensing

  • Configurable license types per tenant — each federation defines its own types (e.g., Sweden: 1 type; France: compétition, loisir, jeune, découverte). Each type has: competition eligibility, insurance inclusion, age limits, duration, renewability
  • License application workflow (club applies on behalf of player → federation reviews → approves → issues)
  • License numbering system (federation prefix + sequential, configurable format per tenant)
  • +121 more
04 400 features

Competition Management

  • Multi-level calendar (world, continental, national, regional, club) — PL-F0401a
  • Calendar event types (championship, open, league, friendly, training) — PL-F0401a
  • Date conflict detection across levels — PL-F0401a
  • +397 more
05 103 features

Officials & Judiciary

  • Configurable umpire grade system per tenant — each federation defines its own grade names, count, and progression path. Examples: Sweden (3: distrikts→nationell→internationell), Germany (4: Landesverband→DPV→CEP→FIPJP), France (5: club→départemental→régional→national→international). Grade list is tenant configuration, not hardcoded.
  • Umpire profile (grade, languages, specializations, photo, exam history)
  • Grade progression tracking (configurable path per tenant)
  • +100 more
06 89 features

Coaching & Education

  • Coach registration with qualification level (BF1 Initiateur, BF2 Educateur, Entraineur)
  • Coach profile (qualifications, specializations, experience)
  • Certification tracking and renewal
  • +86 more

Planned

36
02

Identity & Access Management

5
  • ICE/nödkontakt + skyddad medicinsk basinfo (art.9) med break-glass
  • Egen ICS-kalender (SHOULD) — personlig prenumerationsfeed över alla tenants
  • Spara favoriter (NICE) — favoritklubb/-venue/-spelare/-tävling
  • Tenant-medlemsregister — admin listar den aktiva tenantens medlemmar och öppnar en LIVE profil-detalj
  • +1 more
08

Finance & Billing

17
  • ✅ Online payment gateway integration (Stripe, PayPal, local providers)
  • ✅ Bank transfer payment matching
  • ✅ Installment payment plans (split license fee over months)
  • ✅ Refund processing
  • +13 more
09

Communication & Media

8
  • Feed-detaljens mätta fält: subscribers, latest_sequence och latens mot latency_target_ms
  • Samtyckesgrinden gäller genom kitet: en bilaga utan giltigt samtycke utelämnas helt och räknas i omitted_asset_count
  • Preview av utkastet genom samma renderare som den publika rutten, sidoeffektsfritt
  • Innehållskällan: D-COMM:s publicerings-projektion syndication_item + den interna ingestion-sömmen UpsertSyndicationItem (idempotent på (tenant_id, source_domain, source_ref)), med DB-CHECK:en publication_scope in ('tenant','global') så private/orgnode inte ens KAN skrivas
  • +4 more
11

Commercial & Marketplace

4
  • Ärlig m-3-gräns (inget fabricerat) — ingen SSE-ström, damage_pending fortfarande onåbar, inget skadeärende och ingen cancelled-yta på överlämnings-token (D-10). Custody-mandatet prövas i tenant-scope, inte per nod (D-12). Depositionen levereras av m-4 t-1 (F11.15.16); frakt/spårning, skada + F1-6-bestridning = m-4 t-2; UI = m-5–m-7
  • Ärlig m-4-gräns (inget fabricerat) — inga riktiga carrier-integrationer (porten finns, adaptern är fake-carriern), ingen SSE-ström (spårningen är polling med ETag — m-7), ingen media-uppladdning (foton är https://-referenser), ingen moms på skadeersättning (vat_lines: [] — BILL:s beslut), ingen fri PL-satt delreversering och ingen egen webhook-mottagare/tvist-FSM. Frontend-ytorna (hyresgästens spårnings-/skadevy, PL:s skadeärende-konsol) är m-5–m-7
  • Ärlig m-5-gräns (inget fabricerat) — hyresgästens spårnings-, skade-/bestridnings- och custody-/distributionsvy byggs i m-6; PL:s systemägar-vyer (lager-dashboard, bokningskö, skadeärenden, intäkts-/beläggningsrapport, custody-override) i m-7; inget publikt bokningsflöde eller publikt kvitto på webben (ytbeslut — det kräver ett eget mockup-/kontrakts-delta, ingen attrapp byggs under tiden); ingen provider-SDK för depositionens SetupIntent i UI:t (deposit_setup_client_secret renderas aldrig — hemligheten når inte ytan) och ingen förlängningsdags-rad (prismotorn har ingen sådan prissättning). PL:s driftsteg (confirm-shipment, inspection, close) finns inte på hyresgästens yta — och därför bevisas kvittera/returnera i L4-drivrutinen som request-bevis (POST …/return med If-Match) i stället för en genomförd övergång: ingen seedad dev-login-identitet bär equip:admin, och att driva seedens in_use-fixtur vidare hade gjort körningen icke-omkörbar (redovisat i drivrutinens huvud, aldrig ett tyst grönt)
  • Ärlig m-6-gräns (inget fabricerat) — ingen SSE-ström (färskheten är polling med ETag; strömmen + PL:s live-drift är m-7), ingen generisk F1-6-approval-yta (bestridningen projiceras på skaderapporten — begäran lever i PL:s tenant-noll), ingen fotobilaga i appen (foto-åtagandet ligger i admin, där medie-sömmen finns), inget kameraberoende (fångstadaptern använder plattformens egna sömmar), ingen offline-kö för custody (serverns klockprövning mot expires_at är kontraktet) och ingen force-return/lager-/bokningskö-/intäktsvy — PL:s systemägar-ytor är m-7. PL-driftens steg (confirm-shipment, POST …/shipments, damage-report, charge) kräver equip:admin i plattforms-tenanten och bärs av ingen dev-login-identitet: L4-drivrutinerna mäter det gapet och redovisar det med ⊘ i loggen i stället för att gissa (ett färskt skadeflöde och ett NYTT spårningsnummer kan därför inte drivas utan en ny seed/identitet, vilket m-6 uttryckligen förbjuder)
13

Events & Tourism

1
  • Ytorna: webbintagets event-delta, adminens arrangörskonsol och sys-sektionen
16

Platform Operations & Cross-Cutting Concerns

1
  • Per-tenant retention-policy + retention-drift (Go-rebuild 742fe3db.m-3, D-GDPR m-3) — data_retention_policy (migration 00128) med regler per kategori (tolv validerade kategorier, retention_days 0 = obegränsad, art. 6-grund) och högst en aktiv policy per förbund som databasinvariant. CRUD GET/POST /v1/data-retention-policies + PATCH/DELETE /{id} (capability gdpr:manage, If-Match, soft-delete); 422 retention_rule_invalid och 422 retention_below_statutory_minimum (accounting 2555 d, gdpr_notifications 1825 d enligt art. 33(5)). whistleblower_records har INGEN fast tid — EU 2019/1937 sätter ingen, så kategorin är per-tenant/land-konfigurerbar med subcategory ∈ {investigated, not_investigated}; ett källkodstest bevisar att ingen kodväg bär en femårsgräns. Retention-svepet gdpr_retention_sweep gallrar via SAMMA RetentionGuard-väg som Art. 17-raderingen (två registrerade källor: consent_record, profile_photo). Sys-driftvyn GET /v1/sys/compliance/retention (capability sys.support.lookup) + sys/app/efterlevnad/retention visar konfigurerad TTL mot äldsta observerade rad per förbund och kategori, med avvikelse-badge som bär ordet "Avvikelse" och lägena upprätthålls/observeras/saknas — en kategori utan källa redovisas ärligt som *saknas*, aldrig som grön. Se specs/sys/views/compliance-retention.md + specs/api/endpoints/retention-guard.md.

Missing Something?

Your feedback shapes our roadmap. Submit a feature request and help us build the platform you need.