Support location-scoped notification subscriptions (location.feed_added)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
Direzione di ricerca
Start with the API schema in docs/UserServiceAPI.yaml and the existing subscription creation and response code for POST /v1/user/subscriptions; the issue does not name the implementation files or tests. Trace how subscriptions currently reference targets, then determine how the new location join table fits the database layer. Done means the endpoint creates a subscription for the supplied location IDs and returns those IDs, with the required validation enforced in code.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
location.feed_added alerts a user when a feed is added for a location they follow, so a subscription must carry the list of locations. We'll add a dedicated notification_subscription_location join table and expose the location list through the API.
Notification type in scope
| Notification type | Target |
|---|---|
location.feed_added |
list of location IDs |
Schema changes (docs/UserServiceAPI.yaml)
Add location_ids to the create request and to the subscription response:
CreateNotificationSubscriptionRequest:
properties:
# ...notification_id...
location_ids:
type: array
items:
type: string
description: Location IDs to subscribe to. Required for location.feed_added.
NotificationSubscription:
properties:
# ...existing fields...
location_ids:
type: array
items:
type: string
nullable: true
description: Locations this subscription targets (location.feed_added).
Code changes
- POST /v1/user/subscriptions creates one subscription referencing all supplied locations and returns it with location_ids populated. _Validation is enforced in code, not the schema. Per-type schema validation would need oneOf/discriminator or JSON Schema if/then/else (3.1 only; this spec is 3.0.0), and union typing was already abandoned here due to openapi-generator limitations (see docs/DatabaseCatalogAPI.yaml SearchFeedItemResult).
DB changes
Add new relation table between user subscriptions and locations
- Lingua principale
- Python
- Stelle
- 34
- Fork
- 7
- Merge medio
- 12h 7m
- PR unite (30g)
- 7
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MobilityData/mobility-feed-api
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
MobilityData/mobility-feed-api#1846 ·
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
MobilityData/mobility-feed-api#1755 · 1 reazione ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
MobilityData/mobility-feed-api#1647 ·
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
Tutte le issue di MobilityData/mobility-feed-api
Issue simili
-
infrastructure
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
khuisman/mcp-gee-sweet#1152 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
backroom bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
ditto-assistant/ditto-subnet#3069 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
open-webui/open-webui#32901 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
0.3.3 bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno