Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Set unpublishable: true on PublishedChange by construction to simplify handleMaxRevs predicate

Abierto Apto para principiantes
  • ¿Algo no está bien?
#5,868 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
74/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
javascript
Área
backend

Línea de trabajo

Comienza con los constructores de PublishedChange y PublishedNextChange en changes.js y, después, inspecciona el predicado lastChannelEditIndex en serverSync.js. Actualiza los constructores y elimina la condición de tipo redundante. Luego ejecuta las pruebas existentes de PublishedChange en changes.spec.js y verifica que unpublished_changes siga siendo correcto después de un evento de publicación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

DEV: frontend P3 - low

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Current behavior

In serverSync.js, handleMaxRevs uses findLastIndex to compute two values for deciding whether to set unpublished_changes = true on a channel:

  • lastChannelEditIndex — the last publishable change, filtered (among other conditions) with c.type !== CHANGE_TYPES.PUBLISHED
  • lastPublishIndex — the last publish change, matched with c.type === CHANGE_TYPES.PUBLISHED

The predicate for lastChannelEditIndex already includes !c.unpublishable, making the explicit c.type !== CHANGE_TYPES.PUBLISHED check partially redundant: if PublishedChange always set unpublishable: true, the type check would be unnecessary.

Desired behavior

PublishedChange and PublishedNextChange set unpublishable: true by construction (in its constructor in changes.js), so the c.type !== CHANGE_TYPES.PUBLISHED guard in handleMaxRevs can be removed. The !c.unpublishable check alone is sufficient to exclude publish changes from lastChannelEditIndex.

This makes the semantics self-contained in the change object — callers don't need to know the type mapping — and reduces the risk of future change types being accidentally treated as publishable.

Acceptance Criteria

  • PublishedChange constructor in changes.js sets unpublishable: true unconditionally
  • The c.type !== CHANGE_TYPES.PUBLISHED condition is removed from the lastChannelEditIndex predicate in handleMaxRevs (serverSync.js)
  • Existing tests for PublishedChange in changes.spec.js pass (updated if needed to assert unpublishable: true)
  • unpublished_changes continues to be set correctly after a publish event (no regression)

References

Follow-up to https://github.com/learningequality/studio/pull/5844#discussion_r3125011603

AI usage

This issue was drafted with Claude Code assistance from session context and code review.

Lenguaje dominante
Python
Estrellas
191
Forks
308
Merge medio
2 d 17 h
PR fusionados (30 d)
64

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de learningequality/studio

Todos los issues de learningequality/studio

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.