Store Inbox snooze and pins on the server, with event-based snooze
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- backend, full-stack
Línea de trabajo
Start with inboxSnooze.ts and the Inbox implementation linked in #3036; trace how snooze and pin state affects the Inbox and navigation count. Then read the watch event handling for events such as pull_request.merged and deployment.succeeded. Done means snooze and pins are stored per viewer on the server and matching events can reopen snoozed items across devices.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The dashboard Inbox (#3036) keeps snooze and pins in the browser only. Other devices and the nav count do not see them.
Current behavior
- Snooze and pin state lives in the browser (
inboxSnooze.ts). It is lost when you switch device, and it does not change the Inbox count in the nav. - Snooze only supports times.
Gap
- Snoozed and pinned Review items should look the same on every device and in every count.
- Many Junior asks only become actionable after an event, not at a time. Examples: a PR opens, a PR merges, a deployment finishes, or an Automation runs.
Proposal (raised by BYK): store snooze and pins per viewer on the server, and add "when" snooze conditions, in the spirit of Google Inbox's location-based snooze. Examples: "when automation X runs", "when this PR opens", "when this PR merges". Junior already delivers provider events such as pull_request.merged and deployment.succeeded to watches, so an event-based snooze could reopen the item when a matching event arrives.
Related: #3036, #3103.
via @BYK.
--
- Lenguaje dominante
- TypeScript
- Estrellas
- 397
- Forks
- 43
- Merge medio
- 8 h 28 min
- PR fusionados (30 d)
- 764
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de getsentry/junior
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
Todos los issues de getsentry/junior
Issues similares
-
area:tooling good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
interledger/publisher-tools#1007 ·
Los mantenedores suelen responder en 1 día
-
priority/medium roadmap/v1.1.1 stakeholder/rapr type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
databrickslabs/ontos#1420 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
vercel-labs/just-bash#756 ·
Los mantenedores suelen responder en 1 día
-
area: ci good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
interledger/web-monetization-extension#1555 ·
Los mantenedores suelen responder en 1 día
-
[t-dialog] 弹窗组件和抽屉组件的文档说明不够详细清楚Abierto🐞 bug 🧐 unconfirmed
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Tencent/tdesign-vue-next#7056 · 1 comentario ·
Los mantenedores suelen responder en 1 día