Etherpad-lite: La autoría de las viñetas cambia cuando un segundo autor las edita

Creado en 27 mar. 2018 · 12Comentarios · Fuente: ether/etherpad-lite

Esto se ha recreado tanto en nuestra versión interna de etherpad como en beta.etherpad.org (https://beta.etherpad.org/p/tapril_test).

Cuando un autor agrega contenido a una lista de elementos con viñetas, la autoría indica correctamente el autor. Una vez que un segundo autor modifica la viñeta, la autoría de la viñeta completa cambia al segundo autor y cuando se usa el complemento de autor de desplazamiento, el nombre del autor se muestra como "[objeto ojbect]".

No recuerdo que esto sea un problema en 1.5.1 o antes, pero no he tenido la oportunidad de ir y hacer una búsqueda binaria en las versiones para averiguar dónde se introdujo el error.

Black hole bug Bug

Fuente

timapril

👍1

Comentario más útil

Ok, después de un (largo) tiempo, pude encontrar una manera de manejar todos los escenarios, y este problema finalmente se solucionó.

lpagliari en 9 jul. 2018

🎉3

Todos 12 comentarios

Estoy bastante seguro de que esto es un duplicado, ¿no?

JohnMcLear en 3 abr. 2018

@JohnMcLear Acabo de volver a leer la lista de problemas abiertos y no puedo encontrar nada que me haga pensar que este es un problema duplicado. También miré más de cerca los resultados de la búsqueda de "color" y "autor" sin suerte para encontrar un dup.

timapril en 3 abr. 2018

@lpagliari , esto frustra a muchos de mis colegas. ¿Tienes alguna actualización?

benlind en 6 jun. 2018

👍1

lo siento, chicos, últimamente no tuve tiempo de concentrarme en Etherpad. Intentaré echarle un vistazo en los próximos días.

lpagliari en 8 jun. 2018

Podría reproducir el primer problema (el autor de la línea ha cambiado por completo), pero no el segundo (el nombre del autor se muestra como "[objeto ojbect]" _). Sigo investigando las causas ...

lpagliari en 11 jun. 2018

Hola @lpagliari , ¿Has tenido la oportunidad de ver el problema del autor de la línea? Realmente podríamos usar una solución para esto, incluso si no ha tenido la oportunidad de ver el segundo problema.

dgoldfein en 25 jun. 2018

@dgoldfein sí, he estado investigando el problema durante los últimos dos fines de semana. Todavía no tengo una solución, pero al menos encontré el compromiso que rompió el comportamiento. Estoy buscando cómo solucionarlo ahora.

lpagliari en 2 jul. 2018

👍2

Ok, después de un (largo) tiempo, pude encontrar una manera de manejar todos los escenarios, y este problema finalmente se solucionó.

lpagliari en 9 jul. 2018

🎉3

@lpagliari , ¡Gracias por arreglar esto! Probamos el código de desarrollo en nuestro entorno de prueba y las correcciones funcionaron. ¡No puedo esperar al próximo lanzamiento oficial!

dgoldfein en 10 jul. 2018

@lpagliari ¿ Algún cambio para que esto se convierta en un lanzamiento oficial? ¿A quién debo contactar sobre eso?

dgoldfein en 23 jul. 2018

Supongo que @muxator podría ayudarnos aquí ... ¿Algún plan para una nueva versión, @muxator?

lpagliari en 24 jul. 2018

Mi principal preocupación es # 3268: corrige un error, pero rompe los complementos.
Si este cambio tuviera un caso de prueba claro (ver # 3425) podríamos aceptar la rotura, siempre que aumentemos el número de versión a 1.7 ( hito ) y tengamos un plan de comunicación claro.

Si tuviera que cortar un lanzamiento ahora mismo, haría: