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

CustomAlerts API uses inconsistent parameter and response names compared to the rest of the Reporting API

Aperta
#250 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
php

Direzione di ricerca

Traccia le definizioni dei parametri e delle risposte di CustomAlerts.addAlert, CustomAlerts.editAlert e CustomAlerts.getAlerts, quindi confronta la loro denominazione con quella delle altre entità di Reporting API. Riproduci le chiamate curl documentate e conferma il completamento quando siano coperti alias compatibili, un nome di risposta coerente e l'aggiornamento richiesto del changelog senza compromettere i client esistenti.

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

Descrizione

Summary

The CustomAlerts plugin diverges from the conventions used everywhere else in the Matomo Reporting API in two ways:

  1. Singular vs plural site parameter. Every other entity (Goals, Segments, Annotations, ScheduledReports, ...) uses idSite (singular, scalar). CustomAlerts.addAlert and CustomAlerts.editAlert instead require idSites (plural, array).
  2. camelCase vs snake_case in the response. CustomAlerts.getAlerts surfaces the same field as id_sites (snake_case, plural, array) in the response payload, while the mutation endpoints expect idSites (camelCase). A consumer cannot blindly round-trip a list response back into an editAlert call.

Reproduction

# 1. List alerts, observe the response key is `id_sites`
curl -s "https://demo.example.org/index.php" \
  -d "module=API" \
  -d "method=CustomAlerts.getAlerts" \
  -d "format=JSON" \
  -d "token_auth=$TOKEN"
# => [{ "idalert": 1, "id_sites": [1, 2], ... }]

# 2. Try to edit using the response keys verbatim, fails
curl -s "https://demo.example.org/index.php" \
  -d "module=API" \
  -d "method=CustomAlerts.editAlert" \
  -d "idAlert=1" \
  -d "id_sites[]=1" \
  -d "format=JSON" \
  -d "token_auth=$TOKEN"
# => { "result": "error", "message": "Please specify a value for idSites" }

# 3. Same call with `idSites[]=1` works

Expected

Either:

  • The response uses idSites (matching the input contract), or
  • The input accepts id_sites as an alias.

And the idSites (plural) parameter should ideally accept the canonical idSite (singular) like the rest of the API, even if only as an alias for backwards compatibility.

Actual

Consumers must implement a CustomAlerts-specific translation layer just to mirror the data they just read.

Suggested fix

  1. Accept both idSite and idSites on input (alias). Document idSite as preferred, deprecate idSites.
  2. Return the field as idSites (camelCase) in getAlerts, keep id_sites as a short-term alias.
  3. Tag the change in the plugin changelog so consumers can detect the version cutoff.

Impact

Every Matomo client library has to special-case CustomAlerts. Centralizing the rename reduces consumer code across the ecosystem.

Lingua principale
PHP
Stelle
17
Fork
24
Merge medio
1g 6h
PR unite (30g)
7

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

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 matomo-org/plugin-CustomAlerts

Tutte le issue di matomo-org/plugin-CustomAlerts

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.