issue_id;issue_description_final;f_nf_classification;relevance;moscow_categorization;mandatory
1153;[Aula Virtual] Popup de la lista de participantes se muestra por debajo de la actividad actual. ;LF;4;3;
1126;[Gestión] Permitir asignar cualquier nivel. En una prueba de nivel, el profesor debe poder asignar cualquier nivel al estudiante (del idioma correspondiente, claro), no debemos limitarlo a la que ha indicado el propio estudiante en su solicitud.;F;4;4;
1113;"[General] Gestión de contenido de usuario multilínea en ""teachers notes"". Las ""teacher's notes"" de una actividad se muestran en una sola línea. Entiendo que sería preferible que se conserven los saltos de línea en la presentación el contenido.  Por otra parte, las teachers notes se están presentando de dos formas diferentes: como texto (en la vista de actividad) y como html (en la modal). La visualización debería ser uniforme, y dado que no saben usar html creo que debería mostrarse como texto en ambos sitios (prescindir de v-html en la modal).  Una solución simple sería reusar un componente que ya gestione los saltos de línea, como el propio v-textarea, o algo específico que haga split('\n') del texto para presentar cada bloque en un párrafo/div nuevo.  Algo similar ocurre con los campos ""About me"" de los usuarios (es posible que haya otros casos). No abordaremos en esta issue esos casos, pero la idea es que la solución que se use en el componente que muestra el texto sea genérica.";US;4;3;
1107;[Contenidos] Mejorar visualización al ordenar actividades. Cuando se ordenan actividades, el cambio es instantáneo y nos indican que resulta complejo darse cuenta de los cambios que se han producido. Nos solicitan algún tipo de animación que permita ver claramente cuando se produce el intercambio de dos filas.;LF;3;3;
1104;[Gestión] No usar unitOrder. En varios puntos se usa el unitOrder de una Unit, que no se está definiendo al añadirlas. Como corrección rápida, hacer estas ordenaciones por id. Por el momento no parece necesario almacenar el unitOrder dado que no permitimos modificarlo.;F;3;4;
1101;"[Gestión] Mensaje al restablecer contraseña. Mostrar aviso: ""Su contraseña ha sido restablecida. Por favor revise su email""";F;3;3;False
1100;"[Gestión] Información de estudiante vinculándose como tutor a sí mismo. Mostrar una alerta más específica si entro en la página de vincular tutor a estudiante con la cuenta del propio estudiante. Algo como ""Esta cuenta de estudiante no se puede vincular como tutor de sí mismo"".  En vez de mostrarlo como ahora, como un aviso de error al pulsar en confirmar, deberíamos mostrarlo al cargar la página ya, y deshabilitar el botón de confirmar, para que sea más claro.";F;3;4;
1099;[Gestión] Dashboard editor de contenidos: enlaces incorrectos. Si selecciono filtrar contadores de cursos/actividades incompletos para un idioma determinado, al redirigir a los listados deberían mostrarse los listados filtrados para dicho idioma.  ;F;4;4;
1085;[Contenidos] Separar los topics del resto de temas en los listados de actividades. - Convertir el actual selector de temas (en la lista de actividades y en los buscadores para clases/lecciones) en dos separados: uno de skills y otro de gramática/vocabulario. - Separar los listados para incluir el skill/habilidad en una columna separada también, antes de los temas (listado de actividades principal, los buscadores de clase/lección y la lista de seleccionadas en esos buscadores).;F;2;3;
1077;"[Contenidos] Mejora en el ""borrado"" de actividades. Ahora mismo la funcionalidad de borrar una actividad la borra físicamente. Se comproueba si se está utilizando, y si está asociada a alguna clase o lección no se permite. Esto es correcto pero les obliga a mantener versiones antiguas de actividades que ya no usan. La idea es cambiar al mismo modelo que se usa para otras entidades: que el borrado ""marque como borrada"" la actividad, de forma que deje de aparecer en los listados.  ";F;4;3;
1068;[Gestión] Añadir loading al selector de ficheros del formulario de actividad. El selector que indico en la imagen no tiene ningún loading para indicar que se está cargando el fichero.;O;3;3;
1060;[Chat] Abrir chat específico cuando la ventana ya está abierta. Si estás en el perfil de un usuario, por ejemplo, y le das a abrir el chat con ese usuario cuando ya tienes la ventana de chats abierta (con el listado de mensajes o con otro chat), no hace nada, cuando debería abrir el chat del usuario al igual que hace cuando la ventana de chats está cerrada. ;F;4;3;
1058;"[Gestión] Añadir ""notas  del profesor"" a las actividades. Añadir un nuevo campo ""teacherNotes"", de texto multilínea, a las actividades. El campo servirá para indicar características de las actividades; además de en la vista de actividades, para editores de contenidos, este campo se mostrará en un popup (solo para el profesor) tanto en el detalle de una clase->actividad como en la propia aula virtual.";F;2;3;
1057;[Aula Virtual] Filtrar los contenidos que se pueden listar y añadir por el idioma de la lecture. Se está haciendo en la página de edición de la lecture, pero luego en el aula virtual se están mostrando todos los contenidos.;F;4;3;
1053;"[UI] Vista de añadir actividades. En el buscador de actividades (para añadirlas a una clase o lección), en el listado de actividades seleccionadas:  - Añadir títulos de columna. Renombrar el bloque a ""Actividades seleccionadas"", ya que puede ser más de una. - Añadir las mismas columnas que en el buscador inferior. En particular, el tipo de recurso es importante, porque si añado un link me cambia a ""modo deberes"" pero no tengo forma de saber qué actividad es la que lo está forzando.";F;4;4;
1052;"[Contenidos] Cambiar atributos de actividades. Para facilitar el uso de las actividades, vamos a cambiar el nombre y propósito de dos atributos (podemos cambiarlo solo en la vista, sin modificar el modelo):  - Título -> Código - Descripción -> Nombre  Hay que revisar tanto las vistas de los editores de contenidos como las vistas de detalle de una clase/lección a las que acceden los estudiantes, y la vista de deberes de los estudiantes.  El objetivo es proporcionar en el nuevo campo ""Nombre"" algo que sea más indicativo de lo que se va a hacer en la actividad, y que los estudiantes siempre vean este valor. Para ello, tendremos que añadirlo en varias vistas en las que ahora solo estaba el título: - En el detalle y formulario de actividades, incluir ambos campos en la parte superior, junto con el tipo. El ""Nombre"" tendrá un campo de texto normal, no multilínea. - En los listados de actividades de una clase, mostrar el ""Nombre"" siempre, al lado del código donde hubiese código. - En el listado de deberes de un estudiante, mostrar el ""Nombre"" (actual descripcion), en lugar del ""Código"" (actual titulo)";F;3;3;
1051;[Contenidos] Separar idioma y nivel. En los listados de wordlists, cursos, <s>contenidos</s>, actividades/media library:  - Separar en dos columnas idioma y nivel - Añadir filtros de búsqueda por idioma/nivel;F;4;3;
1048;"[Gestión] Panel de control por idioma.  Se pide que los editores de contenidos puedan ver datos limitados a su propio idioma. Por el momento solo lo haremos en el dashboard:  - Añadir un selector de idioma, que permita seleccionar entre ""todos"" y los disponibles. Al actualizarlo, se recargará el panel de control con el filtro de idioma correspondiente. - Guardar la selección realizada en el almacenamiento local, para que sucesivos accesos de un content editor en el mismo equipo recuerden la selección realizada.";US;3;3;
1042;[Gestión] Mejoras en la solicitud y programación de pruebas de nivel. - Añadir un canal de chat estudiante/profesor una vez la prueba está programada - Al cargar el aula virtual, para las clases que sean de prueba de nivel, puede cargarse este canal como editionChat, de forma que al pulsar en el icono de chat se abra este por defecto (no es necesario hacerlo en el detalle de una lecture porque allí ya tenemos un acceso visible para el chat del estudiante).;F;4;4;
1040;"[Gestión] Mostrar el último curso y actividad para un editor de contenidos. Mostrar, para un editor de contenidos, dos entradas adicionales en su panel de control que indicarán el último curso y la última actividad en las que ha entrado.  - Cuando un contenteditor entre a editar un curso/actividad, almacenar el valor correspondiente en el localStorage, en el cliente. - En el dashboard de un content editor, comprobar si los atributos de último curso o última actividad existen en local storage. Si existen, mostrar una ficha en el panel de control ""Último curso accedido"" con el nombre del curso y un enlace a la ficha, y lo mismo para una actividad.";F;4;3;
1035;[General] Visualización de listados. Elementos a revisar en los listados de la aplicación, que en principio deberían ser simples (si alguno es complejo se moverá a otra issue): - Utilizar colores alternos para las filas;LF;4;4;
1035-2; Cambiar las opciones de filas por página:   - Opciones: 10, 25, 100, todas (añadir 25)   - Valor por defecto 10;LF;4;3;
1035-3;Revisar tooltips: todos los iconos de acción deberían tener tooltip asociado ;LF;4;4;
1034;[Gestión] Accesos directos a chats v2. Algunas ampliaciones y pequeñas mejoras sobre lo hecho en #942  - El profesor también debería tener acceso al chat de la edición (además de a los individuales con alumnos) ;F;4;3;
1034-2;En el detalle de una clase, vista de profesor, ajustar los iconos de chat para que encaje todo en una fila (si hay botón evaluar, o asignar nivel, queda colocado de forma extraña);F;4;3;
1034-3;Creo que sería más práctico que el botón de chat del aula virtual por defecto abra el chat de la edición actual, igual que en detalle de una lecture, aunque luego permita volver atrás y ver el listado completo. Otra opción sería poner un segundo botón de chat en otra ubicación, pero eso a mí me parece que puede ser confuso....;US;4;3;
1028;[Contenidos] Mejorar visualización de listas de actividades. En la lista de actividades de una lección de curso (o prueba de nivel): - Quitar los campos de puntuación y tiempo máximo;F;4;3;
1028-2;[Contenidos] Mejorar visualización de listas de actividades. En la lista de actividades de una lección de curso (o prueba de nivel):  Revisar los paddings para evitar que cada entrada sea muy alta ;F;4;3;
1028-3;[Contenidos] Mejorar visualización de listas de actividades. En la lista de actividades de una lección de curso (o prueba de nivel): Revisar los iconos de acción: añadir tooltip a todos ellos;F;4;3;
1027;[Contenidos] Mostrar lecciones colapsadas al expandir una unidad. Cuando expando una unidad, ahora mismo se despliegan las lecciones completas con todas sus actividades. Se pide que sean colapsables también (y creo que tiene sentido en ese caso que sea el comportamiento por defecto). No es necesario cambiar las peticiones al servidor, solo la visualización en el detalle.;US;3;4;
1026;[Gestión] Ver alumnos en dashboard de profesor. En el dashboard de un profesor, en la información de pruebas de nivel próximas, debería ver los alumnos correspondientes a cada prueba de nivel en el propio panel;F;4;3;
1025;"[Gestión] Mejoras en calendarios. - Permitir seleccionar una secuencia de disponibilidades arrastrando sobre el calendario (se marcarán todas las franjas en la sección arrastrada) - Mostrar por defecto el calendario comenzando a las 09:00 en lugar de a las 0:00 (no cambiamos el calendario en sí; la idea es simplemente hacer scroll de la vista del calendario para que al cargarlo inicialmente comience a esa hora, pero podemos subir y bajar como hasta ahora - Ocultar la disponibilidad cuando haya otra cosa en el hueco, para que la clase, por ejemplo, ocupe el espacio completo del horario en el que se encuentra (no vamos a controlar si hay clases solapadas, solo este caso particular de las disponibilidades).";US;3;3;
1024;[Gestión] Permitir a un alumno borrar un cuestionario previo de nivel. Un alumno podrá borrar un cuestionario previo de nivel que tenga en curso. Esto eliminará la asociación con el estudiante y todas las asociaciones de actividades.;F;4;2;
1023;[Gestión] Mejoras en cuestionarios previos de nivel. El usuario podrá escoger no solo el idioma sino también el nivel a la hora de escoger una prueba de nivel  - Modelo: asociar Lesson con Level en lugar de con Language   - Preparar un script de actualización que simplemente establezca el primer nivel del idioma actual para los cuestionarios existentes   - Actualizar test-data. - Cliente:   - El usuario cuando escoja un cuestionario de prueba de nivel podrá indicar el nivel concreto que quiere, no el idioma. Se escogerá como hasta ahora aleatoriamente de entre los cuestionarios disponibles para el nivel indicado.   - En las vistas de Lecture hai que revisar los accesos a Language para asegurar que tomen el idioma del nivel seleccionado. Al menos habrá que revisar los DTOs, y comprobar que LectureDetail sigue funcionando.;F;4;3;
1007;"[Contenidos] Ajustes en el detalle de un curso. En la vista detalle de un curso:  Habría que añadir un botón ""atrás"" que permita volver al listado de cursos.";US;3;3;
1007-2;"[Contenidos] Ajustes en el detalle de un curso. En la vista detalle de un curso: Acortar el nombre de los botones (llega con ""editar"" y ""duplicar"") ";US;3;3;
1007-3;[Contenidos] Ajustes en el detalle de un curso. En la vista detalle de un curso: - Añadir un diálogo de confirmación al botón eliminar.;US;3;3;
1003;"[Chat] Desarchivar canales cuando se reciban mensajes nuevos. Es raro recibir mensajes y que no se ""desarchive"" el canal para poder verlos.";F;4;3;
1000;[General] Refactorizar envío de emails. Ahora mismo siempre se usa multipart=true y HTML = true. Este será el comportamiento obligatorio, pues es necesario para poder usar cabeceras con imágenes. Hay que limpiar el código para quitar los parámetros del método genérico de envío de email para evitar problemas en el futuro;O;4;4;
994;"[Gestión] Mejoras en la activación de usuarios. Si no me llega el enlace de activación por el motivo que sea, debería tener la opción de solicitarlo de nuevo. Propuesta:  - Reusar la misma página que ahora sirve para solicitar un email de reestablecer contraseña, para no añadir más botones en la página de login. Cambiar el texto que aparece en la parte superior de la página para añadir la explicación de este caso (ej: ""Si se ha registrado y aún no ha recibido el correo de activación (compruebe su bandeja de correo no deseado), también puede solicitar un nuevo correo de activación.""), y añadir un segundo botón (""Enviar correo de activación""?). ";F;4;3;False
994-2;[Gestión] Mejoras en la activación de usuarios.  También puede ser útil, y entiendo que es muy sencillo, que si un usuario restablece su contraseña y no estaba activado, se le active también (ojo, esto solo puede hacerse si el usuario está desactivado pero no borrado, es decir, si `dateEnd==null`, si no permitiríamos que un usuario borrado se reactive).;F;4;3;
994-3;"[Gestión] Mejoras en la activación de usuarios. El aviso de ""registrado exitosamente"" debería tener un timeout más alto, e indicar que se recibirá un correo de activación. Algo como (propuesta de Interculturas): ""Por favor revise su email para activar la cuenta. En caso de que no reciba un email de activación en los próximos 30 minutos, puede volver a solicitarla en Olvidó su contraseña- Enviar correo de activación""  ";US;4;3;
991;"[Aula Virtual] Botón de ""unirse al audio"". Cambiar botón para unirse al “audio”. Actualmente cuando desmuteamos el micro nos conectamos al audio. Creo que debería ser un botón diferente, porque lo normal será acceder al audio y posteriormente desmutear el micro (vamos a duplicar el botón de mutear para hacer esto mientras no hay un diseño de dicho botón).  Metemos un botón más ahí, que será el único que se muestre cuando el usuario se conecta pero aún no se ha unido al audio. Al darle a ese botón, el usuario se unirá al audio y se muteará automáticamente. En ese momento es cuando se verán los dos botones actuales.";F;3;3;
990;[Aula Virtual] Controles de la modal de la lista de participantes cuando el profesor está desconectado. Deberían verse incluso si el profe está desconectado. En el caso de un alumno debería verse simplemente si está conectado o desconectado, pero el resto de controler no haría falta.;F;3;3;
982;[Gestión] Mejorar visualización del detalle de una edición.  En las tablas se está mostrando siempre el nombre del curso porque no está especificado en ningún lado en el resto de la vista. Realmente en las tablas no debería salir, puesto que el nombre siempre es el mismo, habría que poner el nombre en la cabecera de la vista junto con otros datos como si el curso está activo y las fechas de inicio/fin.;F;3;3;
980;"[Aula Virtual] Controlar la duración de las sesiones de Zoom. Varias cosas que se me ocurren:  * Mirar de crear nombres únicos para cada sesión de Zoom, que combinen el nombre de la lecture + el timestamp por ejemplo. * Mirar si se puede decir, al crear una sesión de Zoom, algo como ""esta sesión va a durar X minutos"" para evitar que nadie pueda estar posteriormente. * Mirar si se puede ""cerrar"" una sesión de Zoom.  La idea es que si una sesión es de 10 a 11, a las 11 + N minutos se cierre a la fuerza la sesión. Y que si el profesor le da a ""Terminar clase"", se cierre, que esto creo que ya se está haciendo.";F;4;3;
961;[Gestión] Controlar enlace de tutor con estudiante.  Cuando envío varias peticiones a un usuario para ser mi tutor, ese usuario puede aceptarlas todas. Es decir, si como *studentcandidate1* envío una petición al *teachercandidate1*, luego le envío otra y desde *teachercandidate1* se hace click en los dos enlaces enviados en ambos correos, puedo registrarme dos veces como tutor de ese estudiante, no hay nada que me lo impida.   Hay que mostrarle un error al usuario indicándole que ya es tutor de ese estudiante y habría que eliminar por tanto esa fila en la tabla t_tutor.;F;3;3;
958;Reimplementar h5p-server. Resulta que al final no hace falta hacer cambios sobre el código original de lumieducation. Por lo tanto, vamos a reimplementar el servidor de contenidos de h5p para poder usar las librerías originales.;O;4;3;
956;"[UI] Copiar disponibilidades. Seleccionar el botón ""copiar disponibilidades"" debería activar el botón de guardar, sin que sea necesario hacer un cambio en las disponibilidades seleccionadas";F;2;4;
954;[Gestión] Interacción de selector de idioma y nivel. (detectado en creación de una actividad, podría darse en otros componentes)  Inicialmente tengo selector de idioma y nivel en blanco. Si selecciono primero el idioma se filtran los niveles a los del idioma correspondiente(ok), pero si selecciono primero nivel el idioma se queda en blanco, y al seleccionarlo se limpia mi selección de nivel.  Comportamiento esperado: a) si selecciono un idioma y tenía un nivel asociado a ese idioma escogido (me parece lo más claro, y así funciona el formulario de cursos), o b) si selecciono un nivel se cubre el idioma correspondiente automáticamente.;F;2;2;
947;[Gestión] Mejoras en thumbnails. - En el detalle de una actividad, el thumbnail se muestra muy grande en el formulario de la actividad, lo que hace que la actividad se desformatee, al menos en ocasiones. Propuesta: añadirlo reducido siempre, o tenerlo en grande solo mientras la actividad carga.;LF;2;3;
947-2;[Gestión] Mejoras en thumbnails.  Añadir una funcionalidad de borrar el thumbnail actual (solo puede editarse) - Añadir el thumbnail al listado de actividades de una prueba de nivel. Pendiente determinar si también queremos añadirlo en otros sitios  ;LF;2;3;
942;"[Gestión] ""Accesos directos"" a canales de chat. En algunas ubicaciones de la aplicación me gustaría poder encontrar fácilmente el canal de chat que necesito para hablar con un usuario o un grupo. El buscador sirve para los casos generales, pero en los siguientes casos específicos sería preferible tener un icono de chat que al pulsarlo ya despliegue la ventana de chat con el canal correspondiente abierto. Identifico los siguientes casos:  - Cuando estoy en una clase (en LectureDetail o en la propia aula virtual), me gustaría tener:   - Un botón que abra el chat de la edición   - Como profesor, al lado del detalle de cada alumno (en el aula, en la lista de participantes), un botón que abra el chat con ese alumno   - Como alumno, al lado del detalle del profesor, un botón que abra el chat individual con el profesor. - Como administrador, me gustaría poder abrir directamente un chat con cualquier usuario que estoy revisando. Podría ser suficiente con mostrar el botón en el propio perfil del usario, pero si podemos colocarlo de forma adecuada sería preferible mostrarlo en todas las páginas de ese usuario (en la zona superior, donde ahora se muestra la indicación de que un profesor/estudiante está pendiente de aprobación).";US;3;2;
937;[Gestión] Convertir el login a minúscula en el cliente. En los formularios de registro/login (en general en donde se pueda crear un campo de login) hay que añadir un `@input` que haga la conversión del campo a minúsculas (ahora mismo se está forzando en el servidor pero no se ve en el cliente, por lo que un usuario puede registrarse con su login en mayúsculas y no darse cuenta de que se ha modificado).;F;4;3;
936;[Gestión] Cancelación de clases de cursos finalizados.   Habría que añadir al proceso automático de #892 la cancelación de todas las lectures futuras (incluyendo attendances, activityInteractions...). Creo que xa existe código en algún método para hacer esto, por lo que habría que refactorizarlo a un nuevo método privado al que llamar. ;F;2;3;
935;[Gestión] Añadir loadings a la vista de LectureDetail.  Hay que añadir loading para evitar que un usuario pueda pulsar varias veces sobre asignar como deberes, eliminar actividad, etc. mientras está cargando. Por ejemplo: puedo pulsar sobre asignar como deberes y luego, mientras carga, puedo volver a pulsar y se crean dos peticiones. ;F;3;3;
932;[Gestión] Control de borrado de cursos. Si un curso no se ha usado / está usando deberíamos tener la opción de eliminarlo (internamente lo deshabilitará) igual que con las pruebas de nivel.;LF;2;4;
925;"[Gestión] Cambios en chat con administradores. - En estos canales de chat no debe aparecer el mensaje de ""Se ha unido"" al inicio. - Para los usuarios no administradores, no debería mostrarse el nombre de quien ha respondido, solo una indicación genérica ""Administrador""/""Admin"". - Para los usuarios administradores, no deberían aparecer mensajes pendientes en el canal si el último mensaje ha sido enviado por un administrador (se entiende que los administradores ""responden en grupo""). La implementación más simple (aunque no la más eficiente) entiendo que es marcar como leídos para todos los administradores los mensajes antiguos en ese caso.";F;3;4;
924;"[Gestión] Archivar conversaciones. - Como usuario, quiero tener la opción de ""Archivar"" una conversación del chat.  - Las conversaciones archivadas pueden estar ocultas por defecto (añadir un campo en el buscador de chats para incluirlas)";F;4;4;
923;[Gestión] Controles en el id de facturación. El id de facturación de un usuario (billing_id) no puede tener más de 4 dígitos y debería ser único;FT;4;3;
922;[Gestión] En la vista de una edición, mostrar el estado de las matrículas. Como profesor, entrando en una edición, veo todas las matrículas de esa edición (independientemente del estado). Esto está bien (tengo que valorar a un alumno que se ha daddo de baja, por ejemplo), pero me gustaría poder distinguir visualmente las matrículas activas de las inactivas/finalizadas. Esta distinción debería aparecer tanto a un profesor como a un administrador. Puede ser con un icono especial para las matrículas de baja/finalizadas, o indicando el estado de alguna forma.;F;4;3;
918;[Gestión/Contenidos] Gestión de actividades incompletas. - Si una actividad no tiene contenido asociado, no debería mostrarse en el buscador de actividades - Si una prueba de nivel tiene actividades incompletas, hay que considerarla como incompleta a todos los efectos (no se podrá asignar);F;3;3;
915;"[Chat] Meter un espacio entre el nombre del usuario y el mensaje en la lista de chats. En la lista de chats los mensajes aparece como nombre:mensaje, deberían aparecer como nombre: mensaje; es decir, falta un espacio. Aparte, el nombre debe ir con negrita también. ";LF;3;4;
912;"[Gestión] Clases cercanas. La lista de clases cercanas ahora mismo aparece, para estudiantes y profesores, simplemente como ""Lista de clases"". HAbría que ajustarla para aclarar el funcionamiento: - Cambiar el mensaje a ""Clases cercanas"" o similar. (ojo, el administrador también tiene una lista de clases, pero son todas, comprobar que el mensaje cambiado no se use en otras ubicaciones y si es necesario crear uno nuevo). - En la lista de clases, añadir en la parte superior una indicación de que se están mostrando clases en un intervalo de 24 horas, y que para ver otras clases puede consultarse en el calendario o en ""Mis cursos""";F;3;4;
912-2;[Gestión] Clases cercanas. Tanto en las listas de clases como en el detalle de una clase, añadir el icono de unirse deshabilitado para las clases pendientes si todavía no se cumple el período de tiempo anterior que permite unirse.;F;3;3;
912-3;"[Gestión] Clases cercanas. Añadir un tooltip que indique el funcionamiento (""El acceso al aula se activará 10 minutos antes del inicio de la clase o cuando el profesor la inicie"", o algo así).";F;3;3;
911;"[Gestión] Acceso a mis cursos. Los estudiantes menores de edad podrán acceder a la vista ""Mis cursos"" (sus ediciones), que ahora mismo tienen oculta. Sin embargo, no podrán acceder a varias funcionalidades dentro de una edición (revisarlo): - No podrán ver su valoración final ni descargar el certificado asociado - No podrán solicitar la baja";SE;1;3;
910;"[Gestión] Mensajes de productos/cursos. Uniformizar nombrado de cursos en las interfaces para profesores/estudiantes:  - Como profesor, en la vista de sus ediciones asociadas (""Mis cursos""), deberíamos referirnos siempre a cursos: columna ""Tipo de curso"", filtro ""Mostrar cursos finalizados"" - Como estudiante, lo mismo - En la vista pública de productos (""Productos disponibles""), lo mismo: Tipo de curso - Lo mismo en la vista de detalle de un producto: nos referiremos a curso y no producto  Ojo, todo esto aplica a la vista de usuarios normales. En vistas como el detalle de producto, a la que también accede un administrador, para el administrador deberíamos dejar producto en lugar de curso.";F;4;4;
909;[Gestión] Añadir un usuario a una edición existente. Como administrador, entrando en una edición, quiero poder añadir a un usuario nuevo a esa edición. Esta opción solo debería estar disponible para ediciones en las que el número de personas matriculadas es inferior al máximo permitido, y debería hacer lo siguiente: - Solicitar al servidor la lista de usuarios que tienen una petición de matriculación pendiente en el producto correspondiente y un horario compatible con las clases creadas. - Permitirme seleccionar de entre ellos uno (o más), siempre que no se supere el máximo de personas. - Al guardar deberían crearse la registration y attendances correspondientes al nuevo usuario (cobrándole el resto del mes, en las mismas condiciones que cuando se crea una edición desde cero, además de notificar al profesor de la edición de la nueva alta.;F;4;4;true
908;[Gestión] Iconos en conversaciones. En el chat, en la lista de conversaciones, mostrar un icono personalizado en lugar del genérico que hay ahora. El icono  dependerá del tipo de chat: - Si es una conversación con otra persona, mostrar la imagen de esa otra persona. - Si son notificaciones, un icono de alerta o similar - Si es una conversación con administradores, por ejemplo un icono de help o similar para el usuario, y la foto del usuario (para los administradores) - Para el resto de tipos, un icono más o menos representativo del tipo correspondiente (human-male-board para clases? coffee para sala de profesores? ...);US;4;3;
905;[Gestión] Ids de facturación y generación de PDFs. La idea es que para generar los PDF de las facturas deberíamos tener un id de cliente a incluir en el PDF, que se obtiene de un sistema externo. Cambios a realizar:  - Añadir un campo idFacturación a Invoice - Copiar el campo del cliente al generar una factura. - No permitir descargar el pdf de la factura mientras la factura no tenga un id de facturación asociado.  - Modificar la plantilla de factura para añadir este id de facturación como id de cliente.  Al editar un usurario para ponerle su id de facturación, deberían buscarse las facturas asociadas a ese usuario que no tengan id de facturación asociado y ponerles el valor nuevo (pero no se cambiarán las facturas que tuviesen un id de facturación diferente);F;4;4;
904;[Gestión] indicador de usuarios sin id de facturación. Nuevo indicador para el panel de control del administrador: usuarios que han recargado su monedero (saldo > 0) y que no tienen indicado un id de facturación (creado en #885). Debería mostrarse el contador y un enlace a un listado de usuarios (lista nueva), con sus datos básicos y un icono en cada fila para ir a editar sus datos de perfil.;F;4;3;
896;"[Gestión/contenidos] Detalle de actividades en el buscador. En la lista de actividades que podemos filtrar en el buscador, debería añadirse al menos un campo con el tipo de recurso (me he encontrado con el problema de que estoy añadiendo actividades, me dice ""los links solo pueden añadirse como deberes"" y no sé cual es el link). Si es sencillo, lo ideal sería tener también en esa ventana un botón de previsualizar.";F;3;3;
894;[Gestión] Borrar datos de clases cuando un estudiante se da de baja. Cuando un estudiante se da de baja únicamente se cambia su registro a INACTIVE. Deberíamos también eliminar todas las attendances de las clases futuras y las activityInteractions asociadas a esas clases futuras.  Hay un método ya en *RegistrationService.impl* que hace esa limpieza cuando un estudiante no tiene suficiente dinero en su cuenta para pagar el mes. En este método es el que habría que implementar, por lo que lo mejor sería sacarlo a un método privado para reutilizarlo.;F;3;4;
893;[Gestión] Como administrador, quiero poder finalizar un curso AD_HOC. Hay que añadir un botón a las ediciones de tipo AD_HOC para poder finalizarlas. Seguramente lo más cómodo para el usuario es indicar un fecha de fin para el curso (obligatoriamente posterior a la de hoy), y que sea el proceso de #892 el que marque las registrations como finalizadas.;F;3;4;
892;"[Gestión] Marcar registros como finalizados cuando finaliza una edición. * Crear un nuevo estado para los registros que sea ""FINISHED"". * Marcar los registros con el estado ""FINISHED"" cuando el curso acabe (únicamente a los registros que estén activos).  Todo esto hay que hacerlo en un nuevo método que se ejecute diariamente y compruebe si las ediciones han finalizado.";F;3;3;
891;[Gestión] Impedir acceder a estudiantes a clases en las que no está inscrito. Ahora mismo, accediendo mediante la URL a una clase, te deja entrar siempre, independientemente de si estás apuntado o no al curso.;O;4;3;
890;"[Gestión] Mejoras en clonado y borrado. - Añadir un botón ""clonar""/""copiar"" a la vista de detalle de un curso/prueba de nivel. Al terminar el proceso, entiendo que debería redirigirme a la vista de detalle del nuevo elemento que se acaba de crear. Para mí sería más intuitivo hacer lo mismo también desde el listado (cuando clono algo, que me lleve a la vista de edición de lo nuevo que acabo de crear, en lugar de dejarme en el listado), pero acepto segundas opiniones. ";F;4;3;
890-2;"[Gestión] Mejoras en clonado y borrado. Permitir borrar pruebas de nivel aunque no sean ""editables"" (al marcarlas como desactivadas no debería afectar a los usuarios que ya la habían iniciado por lo que no hay problema por borrarlas aunque no sean ""editables"")";F;4;3;
888;"[Gestión] Buscador de canales de chat. Añadir un buscador al componente de chat que permita buscar canales por tipo/usuario.   Comportamiento básico: - Añadir un botón ""Buscar chat"" que llevará a una pantalla en la que podremos escoger:   - Tipo de chat (usuarios/estudiante-profesor/cursos/sala de profesores/supervisor-supervisado....), podemos mostrar un selector con los que sean aplicables por rol de usuario.   - Buscador de usuario: permitirá buscar entre todos los usuarios de los canales que tenga el usuario actual.  Ya existe una versión preliminar de un componente buscador en el chat, que puede verse con admin, pero que no es funcional. Podemos partir de esa vista, completarla y aplicarla al resto de usuarios.";F;3;2;
887;[UI] Ocultar icono de chat en dashboards. Cuando estamos en un dashboard, no debería mostrarse el chat normal porque ya lo tenemos en pantalla.;LF;3;3;
885;"[Gestión] Ids para facturación. - Añadir un nuevo campo ""idFacturacion: Long"" a UserData. El campo solo será editable como administrador, y solo estará visible para los usuarios que tienen monedero (compañías, estudiantes, tutores) - Modificar el formulario de edición de los perfiles indicados para que incluya el campo. En la vista se llamará ""ID Ofipro"".";F;3;3;true
883;[Gestión] Baja manual de usuarios en ediciones. Como administrador, entrando en una edición, debería poder dar de baja manualmente a un alumno en una edición, seleccionando una fecha de baja (que puede ser la fecha de hoy o cualquiera posterior). Esto implica: - Dar de baja su matrícula, si se escoge fecha de hoy, o marcarla como baja pendiente con la fecha indicada - Eliminar sus attendances (replicar el proceso seguido cuando se da de baja con el proceso automático);F;4;3;
882;[Gestión] Filtrar ediciones pasadas. Actualmente en el listado de ediciones del administrador se muestran todas las ediciones, incluidas las pasadas (endDate < a la fecha actual). Propongo una de las dos opciones:  - Crear un filtro por rango para la fecha de fin de la edición: dos selectores de fechas para establecer el inicio y el fin de la búsqueda sobre la fecha de fin, siendo por defecto la de inicio la actual y la final nula. - Usar un checkbox para mostrar o no cursos pasados, desmarcado por defecto (igual que se hace en el listado de lectures de una edición).  Lo mismo para las ediciones de profesores y estudiantes. Para estos casos creo que será suficiente mostrar solo las ediciones actuales, ya que entiendo que solo interesa mostrar cursos actuales en los que están incluidos.;F;4;3;
879;[Gestión] No mostrar información del monedero antes de haberla cargado. En el panel de control de un estudiante/tutor/compañía, se muestra saldo 0€ en los monederos al cargar la página, mientras se espera por los valores reales del servidor. Debería mostrarse una indicación de cargando, o cuando menos estar el componente completo o los valores ocultos mientras no se recuperen los datos del servidor.;US;4;3;
877;[Gestión] Impedir reasignar el mismo headmaster como supervisor.   Actualmente cuando pulsas en el lápiz para modificar el supervisor de un profesor, te permite escoger el mismo que ya tiene actualmente asignado. Esto provoca que se creen canales de chat adicionales innecesariamente. Hay que añadir un filtro para que en este listado no aparezca el headmaster que ya tiene asignado actualmente, así como añadir controles en el servidor para impedir que se pueda asignar al mismo.  ;F;3;1;
874;"[Gestión] ""Reembolso"" manual. Como administrador, entrando en el monedero de cualquier usuario, debería poder realizar un ""reembolso"" en su monedero de forma manual.  Comportamiento: - En los cargos del monedero (desde la lista de movimientos), debería tener un botón ""reembolsar"" que, tras mostrar un diálogo de confirmación, genere un WalletCharge de tipo refund, asociado al WalletPayment que acabamos de reembolsar (y no asociado a ninguna lecture).  Ojo, estamos reutilizando funcionalidades que ya existen. El comportamiento ahora de la lista de movimientos será: - Si el movimiento tiene un WalletPayment asociado y no es un refund, se entiende que es una transferencia, como hasta ahora - Si el movimiento tiene un WalletPayment asociado y es un refund, se entiende que es un reembolso manual, y debería indicarse ""reembolso del cobro xxxx"" en los detalles. - Hay que revisar los controles actuales, porque ahora tendremos refunds no asociados a ninguna lecture.";F;4;3;
870;[Gestión] Optimizar DTOs de listados.  Actualmente se manda demasiada información a muchos de los listados de la aplicación, por lo que habría que substituir los DTOs utilizados en los listados por otros con la información necesaria (p.e. listados de profesores y estudiantes), bien sustituyendo el DTO de los getAll o creando nuevos endpoints específicos (dependerá si necesitamos que un getAll devuelva tanta información para algún caso).;MN;4;4;
865;[Gestión/contenidos] Ordenar las actividades. Dentro de una lección (y dentro de una clase) debería conservarse un orden entre las actividades asignadas, y este orden debería ser editable por el gestor de contenidos/profesor registrado.  - Añadir el atributo orden a ActivityLesson y ActivityLecture - Configurar una funcionalidad subir/bajar en lessons y lectures - Al programar una edición de un curso, se programarán las activitylecture en el mismo orden especificado en el curso.;US;3;3;
863;[Contenidos] Previsualizar actividades de todos los tipos en los listados. Dentro de un curso, o de una clase, deberíamos tener las opciones de ver el thumbnail y el botón de previsualizar para las actividades de todos los tipos disponibles.;F;3;4;
862;[Contenidos] Añadir thumbnails a otros tipos de contenido. Al menos los vídeos (también podría permitirse para las imágenes) deberían admitir un thumbnail, a mostrar mientras no se cargue el vídeo (ver #861) o en los listados de actividades.;US;3;2;
861;[Contenidos] Rendimiento de vídeos. (indicado en producción) - Error en alguna subida de vídeo (vídeos de tamaño relativamente grande, pero no superior al máximo) - Tiempo de carga bastante elevado antes de mostrarse el reproductor de vídeo propio   - Revisar el proceso de carga del componente   - Poner thumbnail mientras se carga;PE;3;3;
860;[Gestión] Cambiar mensajes de pagos de clases. El administrador tiene una página de liquidaciones (settlements) y otra de detalle, que habla de pagos de clases. En la segunda, debería hablarse también de liquidaciones (liquidaciones de clases, clase liquidada/no liquidada, marcar como liquidada...);F;3;3;
857;[Gestión] Correcciones y mejoras en gestión de extensiones de archivos. - Ignorar mayúsculas/minúsculas (extensión .PDF debería funcionar) - Si cancelo al selección de archivo me sale un error de extensión, no debería salir nada - Revisar las extensiones de vídeo soportados: mp4, webm y mov (confirmado) - Revisar las extensiones de imagen (jpg, jpeg, png y gif funcionan, alguno más?) y documento (permitir ODF, ya que permitimos doc?) - Revisar/añadir un control separado para actividades de tipo documento, que solo permita PDF. La idea es mantener el control genérico de documentos, que permite múltiples formatos, en el resto de ubicaciones de la aplicación, pero tener uno limitado a PDFs para las actividades de tipo documento, dado que se visualizan en el aula virtual. - Informar al usuario de las extensiones. Al menos mostrar las extensiones permitidas en el error que se muestra tras seleccionar. Lo ideal sería mostrar las extensiones permitidas con el selector de fichero, e incluso limitar las que se pueden escoger por el usuario, pero puede quedar pendiente para una issue futura.;FT;4;3;
856;"[Gestión] Desactivar botón de ""Save"" cuando se programa un curso. Cuando estás programando un curso (con la vista de calendario donde se escoge los estudiantes y profesor) y se le da al botón de guardar, este no cambia su estado a loading ni nada, por lo que es posible pulsarlo varias veces y se programan varias veces el mismo curso.  Sólo hay que añadirle un loading y listo.";US;4;3;
853;[Gestión] Enviar notificación al usuario cuando es aprobado. @gdebernardo , tú confirmarás, pero supongo que tendría lógica que, cuando un profesor o un estudiante es aprobado, se le enviase una notificación al chat.;F;4;3;
850;[Contenidos] Hacer accesible la biblioteca multimedia a más roles. ;SE;4;3;
841;"[Contenidos] Cambiar las rutas del módulo H5P evitando la palabra example. h5p-rest-example-server y h5p-rest-example-client son los nombres originales que tenían los módulos de la librería en el momento inicial. Una vez modificados por nosotros y listos para desplegar en producción deberían tener un nombre más ""oficial"".";F;4;4;
831;[Contenidos] Integrar un reproductor de vídeo en la plataforma. Los vídeos subidos por los editores de contenido a la plataforma deben ser reproducibles en la plataforma como cualquier otra actividad, es decir, sin que el alumnado los tenga que descargar.  Los vídeos en el aula virtual NO tienen que ser síncronos, simplemente se comparte y cada alumno le da al play cuando quiere.;F;4;4;
828;"[Aula Virtual] Si el dispositivo que está grabando la clase abandona el aula (cierra la pestaña por ejemplo), debería dejarse de ""grabarse"". Si el profesor cierra sesión ""malamente"", el alumno sigue teniendo el indicativo de que se está grabando, y el profesor cuando vuelve a entrar también.";F;3;3;
823;[Contenidos] Como editor de contenidos, quiero poder mostrar imágenes dentro de la plataforma. Igual que se hace con el visor de PDFs, debería poder subir una imagen y verla como contenido de una actividad de tipo imagen.;F;4;4;
816;[Gestión] Ediciones con menos integrantes del mínimo. - [ ] Mostrar un indicador en el panel de control de las ediciones que tengan menos integrantes del mínimo permitido (solo ocurrirá cuando haya bajas). - [ ] En los procesos automáticos de control de saldo y cobros, utilizar la tarifa del número de usuarios mínimo en caso de estar por debajo de ese mínimo.;F;3;3;
814;[Contenidos] Como editor de contenidos, quiero ver en la lista de cursos una imagen estática de la actividad. El editor de contenidos quiere ver una pequeña imagen (captura de pantalla) en cada fila del listado de actividades para poder distinguirlas a simple vista (no, no llega con descripción y nombre).   Esta imagen deberá meterla el propio editor de contenidos cuando cree la actividad.;F;3;4;
805;"[Chat] Creación automática de canales. Script que se va a ejecutar periódicamente y que gestione los canales de chat creados. En concreto:  * Un canal de todos los administradores. * Un canal de todos los profesores. * Para cada usuario no administrador, un canal con los administradores. * Para cada edición de cada curso, un canal con los participantes en el mismo. * Para cada usuario menor, meter a los tutores en los mismos canales. * Para cada profesor, canal con el supervisor (jefe de estudios).  Además de crear canales y meter a la gente, debería también hacer lo contrario. Por ejemplo, si una persona ya no está en un curso, debería ""deshabilitarse"" el chat (es decir, puede ver mensajes antiguos, pero no los nuevos ni hablar en el chat).";F;3;3;
802;"[UI] Indicación de usuario actual. En el menú desplegable aparece ""Autenticado como XXX"" debajo del nombre a mostrar, pero solo pone ""Usuario registrado"" o ""Administrador"". Propongo: - Indicar el login justo debajo del nombre a mostrar  - Poner debajo la authority actual ""simplificada"" (si es anyStudent poner estudiante, anyTeacher profesor, en otro caso la authority real), sin el texto ""Autenticado como"".  Añadido, a petición de interculturas: - Mostrar también en la vista de perfil el valor del login (no será editable, ni es necesario mostrarlo en el formulario, creo, basta con mostarlo en la vista de detalle de perfil).";US;2;4;
800;[Gestión] Editar las evaluaciones realizadas. Hay 3 evaluaciones en una clase: - El alumno (o su tutor, si es menor) valora la clase. - El profesor valor a un alumno. - El jefe de estudios valora a un profesor.  En los tres casos, las valoraciones ahora no son editables. Deberían serlo, con alguna limitación: - En las valoraciones realizadas por alumnos/tutores, ahora mismo no puede ni verse la valoración realizada. Debería poder verla siempre, y editarla mientras la evaluación no haya sido aprobada/denegada por un administrador y no hayan transcurrido 24 horas desde el fin de la clase. - En las valoraciones realizadas por profesores, deberíamos permitir editarla (nuevamente, podemos limitarlo a las 24h siguientes al fin de la clase). - En las valoraciones realizadas por un jefe de estudios, creo que podemos permitir editarla en cualquier momento.;F;3;3;
799;[Gestión] Acciones del jefe de estudios en una clase de un profesor que supervisa. Un jefe de estudios puede entrar en las clases de un profesor que supervisa y tiene acceso a los botones de editar actividades. Tenemos que cambiar los controles en el servidor para que pueda hacer la asociación de actividades (el control será: puede hacerlo un profesor sobre su clase, o un jefe de estudios sobre una clase de un profesor que supervisa).  Por el contrario, un jefe de estudios no debería poder evaluar a los estudiantes, hay que ocultarle los botones (solo los verá el profesor de la propia clase);F;3;3;
797;"[Gestión] Panel de control gestor de contenidos  v2. Nuevo indicador: pruebas de nivel incompletas: las que no tengan ninguna actividad asociada. Redirigirá al listado de ""Lecture tests"" filtrado por esa condición.";F;4;3;
796;"[Gestión] Usuarios de baja en ""Account management"". Ahora mismo los usuarios que han sido dados de baja se ven normalmente en ""Gestión de usuarios""->""Gestión de cuentas"".  - Por defecto mostrar solo los usuarios que están en activo. Añadir un check ""incluir usuarios de baja"" (desmarcado por defecto) que lo controle. - Si un usuario está de baja, poner la fila en gris (o añadir un icono que lo indique, si resulta más sencillo).";F;4;3;
794;"[Contenidos] Generar marcas pinyin a partir de notación numérica. En el campo pinyin de una palabra (word.pronunciation, solo cuando la wordlist es para chino) se podrá escribir el pinyin utilizando notación numérica (sílabas que pueden ir seguidas de un número que indican un ""tono""). El sistema debe convertir esa notación numérica a los acentos correspondientes a cada número. Ejemplo de conversión: si escribo ""ni3 hao3"" debería ponerme ""nĭ hăo""   He encontrado esta librería:  ""pinyin-tone-convert"": ""^0.0.2"", que define una función ""toneConvert(string):string"" que hace la transformación. Hay otras, y más complejas, entiendo que para esta funcionalidad debería servirnos cualquiera.  La idea es que cuando se escribe en en WordForm la notación numérica, lo que debería guardarse finalmente es la traducción a acentos. Lo ideal sería hacer el reemplazo mientras se escribe, pero si esto no es sencillo puede reemplazarse el texto cuando el campo pierda el foco (al cambiar de campo o enviar el formulario).";F;2;4;
790;[Gestión] Al programar un producto solicitado por una empresa, ver la información fijada por la empresa. En la ventana modal, como administrador, solo escojo el profesor. Sin embargo, el horario seleccionado por la empresa y los estudiantes a matricular deberían aparecerme al menos a modo informativo.;F;4;4;
788;[Gestión] Panel informativo para un profesor. Si no tiene disponibilidades, indicarle que debe indicarlas para poder recibir clases. - Si no tiene CV/displomas, lo mismo - Si no tiene niveles solicitados, lo mismo.;F;3;4;
787;"[Gestión] Panel informativo en el panel de control de un estudiante. En la vista de panel de control de un estudiante queremos mostrar algunas indicaciones de ayuda si el estudiante aún no ha completado los pasos ""normales"" de registro hasta llegar a matricularse en un curso. Este panel puede situarse encima de las fichas existentes, con un borde/fondo que lo haga destacar. Podrá ocultarse con un icono, pero se mostrará siempre por defecto al cargar el panel de control.  - Si el estudiante no tiene ningún cuestionario de prueba de nivel solicitado, mostrar un texto para indicárselo. Algo como ""Para matricularte en un curso debemos evaluar tu nivel en el idioma previamente"". Puedes solicitar un cuestionario de prueba de nivel aquí"" + enlace/botón a niveles. - Si no tiene ninguna clase de prueba de nivel solicitada, pero tiene un cuestionario en curso/realizado, indicarle ""Completa tu cuestionario previo y solicita una clase para verificar tu nivel aquí"". - Si no tiene disponibilidades indicadas, mostrar un aviso indicando ""Cubre tus disponibilidades horarias para poder solicitar pruebas de nivel y matricularte en cursos"" (este aviso puede mostrarse al mismo tiempo que alguno de los dos anteriores). - Si es adulto y no tiene saldo en el monedero, mostrar un aviso que indique ""Recarga tu monedero para poder matricularte en cursos de formación."" - Si cumple todo lo anterior (tiene disponibilidades, tiene un nivel asignado y tiene saldo) pero no está matriculado en ningún curso (ni tiene solicitudes en curso) mostrar un aviso con un enlace al listado de cursos (del idioma en el que tenga nivel) indicando ""Aquí puedes aquí los cursos disonibles y matricularte""  La idea es que vamos a tener avisos similares para profesores (y seguramente tutores), por lo que sería preferible tener un componente genérico para el panel y cada aviso. De todas formas a efectos de esta tarea podemos implementar una versión básica y refactorizar más adelante.";F;3;4;
786;[Gestión] Los indicadores del panel de control de administrador cuentan datos de profesores/estudiantes borrados (de baja).. Tanto en los listados de profesores/estudiantes de baja como en otros asociados aparecen datos de profesores borrados. - [ ] Para la lista de personas, no contarlos - [ ] Para la lista de referencias pendientes, no considerar profesores borrados. - [ ] ;F;4;3;
785;[Contenido] Como content editor, quiero tener acceso al H5P player de cada actividad desde la lista de cursos. Al pulsar en la actividad podría abrirse una ventana modal con el player para que el content editor pueda recordar qué actividad es.;F;3;4;
782;"Ajustes en la listas de clases. En las listas de lectures que ve el administrador, y en las clases próximas que ve un estudiante/profesor, si la clase es de prueba de nivel se muestra ""-"" en el producto.  - Debería mostrarse algo como ""Prueba de nivel - <idioma>"" en ese campo producto - El campo debería llamarse ""Curso"", no producto";F;4;3;
780;"[Gestión] Solicitud de baja en la plataforma. Como estudiante/profesor, puedo solicitar la baja en la plataforma desde mi página de perfil.  - Botón en la pantalla de perfil que permita solicitar baja. Si la persona tiene ediciones en curso, indicarle que no puede darse de baja mientras tenga cursos en marcha. En cualquier caso, debería mostrarse una confirmación que aclare: ""Si solicita la baja en la plataforma, será dado de baja de todos sus cursos y no podrá acceder a la plataforma"". ";F;4;3;
780-2;"[Gestión] Solicitud de baja en la plataforma. Como estudiante/profesor, puedo solicitar la baja en la plataforma desde mi página de perfil.  - Botón en la pantalla de perfil que permita solicitar baja. El botón estará disponible para:   - Estudiantes adultos   - Profesores   - Tutores de estudiantes menores, desde la página del propio estudiante, para dar al estudiante de baja  El cambio que se hará será marcar al usuario como de baja (igual que cuando el administrador lo ""borra"" en su apartado de gestión).";F;4;3;
779;[Gestión] Limitar formatos de fichero. No debería poder escoger cualquier fichero como foto de perfil, solo formatos de imagen (jpg, png, ...)  - Modificar el método de subida de archivos para que pueda controlar formatos aceptados - En la subida de fotos controlar los formatos típicos de imagen.;FT;3;3;
777;[Gestión] Tutores y alumnos adultos. Tenemos que limpiar los tutores de los alumnos adultos:  - Al cambiar la fecha de nacimiento de un alumno infantil de modo que pasaría a ser adulto. Esto puede ocurrir desde el perfil del propio estudiante o desde la edición de un administrador. - Al hacer login como estudiante, debe comprobarse si es adulto y tiene tutores, si es así tenemos que limpiarlos. - Definir un proceso automático diario, que realice la comprobación y limpieza si es necesario sobre todos los estudiantes.   Notas: - Limpiar un tutor significa desvincularlo del estudiante, el usuario del tutor seguirá existiendo y de alta aunque no esté vinculado con el estudiante. Puede ocurrir que quede un tutor sin estudiantes asociados. - El proceso de desvincular un tutor incluye eliminarlo (darlo de baja) de los canales del estudiante (ya se está haciendo al desvincular manualmente);F;4;4;
776;"[Contenidos] Añadir fonética a las palabras. (en espera de priorizar) - Añadir atributo a Word (`pronunciation:String`, por ejemplo) para representar su pronunciación fonética:   - En español/inglés sería la transcripción fonética   - En chino será el pinyin - Añadir el nuevo atributo en la interfaz (no será obligatorio). Idealmente la etiqueta debería cambiar en función del lenguaje asociado a la palabra: si estamos con la wordlist de chino, el campo/columna debería llamarse ""pinyin"", si estamos con otro idioma podría llamarse ""fonética""/""pronunciación""";F;4;4;
774;[Gestión] Proceso automático de limpieza de clases. - Definir un proceso `Scheduled` que se ejecute cada hora y busque clases que no se han finalizado correctamente:   - Clases en estado PLANNED y cuya hora de fin se haya superado hace más de 2 horas: cambiar estado a CANCELLED y enviar una notificación al profesor y a los administradores.   - Clases en estado DOING y cuya hora de fin se haya superado hace más de 2 horas: cambiar estado a DONE y enviar una notificación al profesor y a los administradores.  (usar una constante para el número de horas, será el mismo valor en ambos casos pero puede cambiar en el futuro);F;4;3;
771;[Gestión] Control de acceso a productos. Solo el administrador puede acceder a los productos que no están públicos. El acceso a la ficha del producto y por supuesto la funcionalidad de matricularse deberían estar filtrados en el servidor.;SE;3;4;
770;"[Gestión] Ajustes en vistas de productos. - Listado de productos:   - Vista administrador: mostrar un icono que indique si es de empresa o general (los mismos que se usan en la lista de productrequests). Propongo ponerlo en la columna tipo de curso, al lado del tipo, para ahorrarnos la nueva columna   - Vista pública/estudiantes: ocultar la columna ""Tipo destinatario"", solo tiene sentido para un administrador  - Vista de detalle de un producto:   - Vista pública/estudiantes: ocultar el campo estado  - Formulario:   - Cuando el producto sea de tipo curso, las fechas de inicio y fin serán obligatorias";US;3;4;
766;[Contenidos] Como profesor, veo todos los resultados de las actividades de mis alumnos como si fuesen deberes. Esto es lo que ve el profe, pero la única que hice como deberes es la a12;F;3;3;
756;[Gestión] Formatos de email. Deberíamos ajustar el contenido (y en la medida de lo posible el formato) de los emails a estos patrones que nos pasan (falta el contenido de algunos emails, nos pasarán más ejemplos):  Formato general:Formato solicitud referencias por parte del admin.   Email de activación de usuario.  En la medida de lo posible reproducir los mismos textos en inglés.;F;4;4;
736;[Contenidos] Filtrar automáticamente por nivel en algunos formularios de actividad. Cuando el content editor está metiendo actividades en un curso, deberían salirle automáticamente filtradas por el nivel e idioma del curso. Lo mismo pasa cuando un profe va a meter una actividad no planeada en una clase concreta, automáticamente deberíamos filtrar actividad por idioma y nivel de esa lecture.  Yo lo dejaría filtrado por defecto pero no evitaría que tanto los profes como los content editor puedan cambiar el filtro para elegir otras actividades. Por ejemplo, un alumno concreto le pregunta por pájaros y hay justo una actividad de pájaros en el nivel siguiente que puede resultarle útil.;F;4;4;
735;"[Gestión] Al programar un producto con curso asociado debemos asociar lessons. Al programar una edición de un producto que tenga curso asociado, deberíamos: - Crear una lecture por cada lesson del curso original (independientemente de lo que saliese calculando por fecha de inicio y fin, tenemos que tener al menos una lecture por lesson; en otra issue posterior podemos abordar el control para que la duración que se indique en el producto sea compatible con el curso, o incluso se calcule automáticamente) - Asociar cada lecture con su lesson correspondiente, en orden.  - Vincular las actividades de la lesson con la lecture: crear una activitylecture para cada activitylesson  de la lección asociada, y para cada activitylecture una activityinteraction para cada uno de los estudiantes <s>con dueDate establecida al final de la clase</s> (la dueDate puede estar en blanco)  El objetivo es que tras programar una edición de un curso las clases se correspondan con lecciones del curso y ya tengan actividades asociadas, pues se obtienen de la lesson correspondiente";F;4;4;
729;[UI] Añadir un enlace al detalle de la edición desde el detalle de una clase. Al menos para el profesor;F;4;3;
727;"[UI] Reorganizar información de monederos. - Poner el título (""Monedero"") arriba - Poner el saldo y el próximo pago en la misma ficha - Destacar más el saldo que el próximo pago para que no parezca que es un saldo negativo.   (más parecido a como se ve la info de un estudiante en el panel de control del tutor)";LF;4;3;
722;[Contenidos] Permitir añadir links externos solo como deberes. Ahora mismo se permite añadirlo como una actividad de la clase pero debería poderse añadir solo para ver después.;F;4;3;
708;[Contenidos] Como editor de contenidos, quiero poder asignar deberes por defecto al crear lessons en cursos. ;F;3;4;
707;[Contenidos] Como alumno, quiero subir un pdf de respuesta sin tener que salir del aula virtual. ;F;4;4;
706;[Contenidos] Como profesor/content editor, quiero añadir más de una actividad a la vez en el activity form. Si soy profe o content editor, va a ser un trabajo muy tedioso ir una a una. Podemos hacer que marque todas las que quiera y arriba del formulario salgan todas las que seleccionó con un botón X para borrar por si cambia de opinión.;F;3;4;
705;[Contenidos] Como profesor quiero ver tablas de resultados distintas para actividades NO H5P. Si por ejemplo el/la alumno/a sube un pdf, podemos ocultar el número de intentos y el tiempo consumido. En cuando a la nota, tendría que poder modificarla el/la profe cuando corrija el pdf, ¿no?;F;4;4;
694;[Gestión] No asignar cuestionarios de prueba de nivel vacíos. Cuando se solicita una prueba de nivel, ahora se asocia un cuestionario de entre los disponibles para el idioma. Solo debería escogerse de entre aquellos que tengan al menos una actividad asociada. Si no se devolverá el mismo error que ahora (decir que no hay cuestionarios definidos);F;4;3;
691;[UI] Mejoras en ficha/formulario de perfil/registro. A revisar para todas las vistas de perfil/registro (estudiante/profesor, tutor, genérico (admin,contenteditor), empresa) :  - Formulario: hacer el campo displayName (nombre a mostrar) obligatorio para todos los perfiles - Ficha: la visualización de la dirección cuando no están todos los campos cubiertos muestra comas arbitrariamente, solo incluirlas cuando sean necesarias;LF;4;4;
679;[UI] Maquetación de pantalla de login. ;LF;4;3;
677;[UI] Ventana del chat se muestra demasiado abajo. ;LF;4;3;
675;[Contenidos] Eliminar la opción de filtrar por link en la lista de actividades. ;F;4;3;
674;[Gestión] Mejorar paginación de la vista de movimientos. Tras la realización de la issue https://gitlab.lbd.org.es/lms4.0/webapp/-/merge_requests/558 se ha dejado un array fijo con los mismos valores que los del fichero JS (el tiempo aprieta). Pero en el selector aparece un -1 que no debería, por lo que habría que crear para este caso en concreto un array de objetos que tengan un value-text y que se traduzca. Esto implicará también cambios en la gestión de la paginación dentro del componente, porque habría que settear objetos en vez de un número.;F;4;3;
663;"[UI] Ajustes en calendario. - Quitar en el selector la opción ""Unavailabilities"", y no intentar recuperarlas por defecto (ahora mismo se ha ocultado la opción de editarlas, por lo que no tiene sentido incluirlo). Por el momento no lo eliminaremos completamente del modelo, simplemente ocultemos el acceso. - El nombre del mes está siempre en español";F;4;3;
657;[Gestión] Envío de email de registro aunque falle. Cuando tratas de registrar a un usuario (he probado siendo admin) y tratas de registrar a un usuario poniendo mal uno de los campos (por ejemplo, el email), salta una excepción en el servidor y no crea el usuario, pero a continuación envía el correo de registro como si lo hubiese registrado correctamente.;F;4;3;true
653;[Gestión] Mejorar programación de cursos. A la hora de programar cursos, habría que mejorar varios aspectos: - Mostrar todas las disponibilidades para una clase, en lugar de bloques de 1 hora. - Solucionar que las lectures se creen en la hora programada en el momento, aunque exista un cambio de hora en el medio:   - Para las compañías, guardaría el timezone offset y la timezone con la product request.   - Para los estudiantes, tomaría la timezone y el timezone offset actual del usuario logueado (un administrador, que es quien programa el curso).   - Con estos datos, habría que convertir los horarios de las clases en UTC a la zona horaria con el offset, y de nuevo a UTC para guardar el valor corregido en base de datos.;F;4;3;
651;[Aula Virtual] Supervisor puede entrar en una clase. Hay que modificar el control de acceso para permitir que el supervisor de un profesor pueda acceder a la clase como alumno. Supongo que llega con modificar el método que da la signature de zoom.  Al mismo tiempo, estaría bien revisar las condiciones para poder acceder a una clase, tanto de permisos como de estado. Si una clase es DONE, no debería poder accederse a su aula virtual, no?;SE;3;3;
650;[Aula Virtual] El profesor puede grabar su clase. El fichero debería descargarse y el profesor decide qué hacer con él. Lo más fácil sería tener un botón para grabar y que el fichero se descargue automáticamente al salir de la clase o al finalizar la clase.  ;F;4;3;
647;[Contenidos] Guardar y reproducir las actividades realizadas por los alumnos en una lecture. Resumiendo seria algo como:   1. Modificar la petición donde se guarda el resultado de una actividad para enviar también el JSON que genera la librería de grabar. 2. Crear un botón en el listado de las actividades realizadas en una lecture, que sirva para abrir el reproductor de la actividad realizada.;F;3;3;
640;[Contenidos] En el detalle de una clase de prueba de nivel, como profesor, quiero ver las actividades que han hecho los alumnos en el cuestionario previo a esta clase. Cuando se hace una clase de prueba de nivel, desde el detalle de la clase, sería útil que el profesor pueda acceder (bien en la propia vista de detalle, bien con un enlace a otra pantalla) la lista de tareas que han sido resueltas por el estudiante. Estas tareas no están asociadas directamente a la clase, sino a la Lesson del cuestionario previo.;F;3;4;
638;[Contenidos] Como profesor, quiero poder ver los pdfs subidos por mis alumnos. ;F;3;4;
637;[Contenidos] Adaptar la vista de actividades/links dentro de curso para que sea igual a la vista general. Al entrar en Course List/Course/Unit/+Activity se abre una vista para seleccionar actividades que debería ser idéntica a la vista general de actividades (incluyendo los mismos filtros, la misma separación de links y actividades, etc.).;F;3;3;
636;[Contenidos] Como editor de contenidos, al crear/editar contenido H5P de una actividad me redirige a un Unauthorized. ;F;3;3;
634;[Gestión] Como profesor, quiero ver mis listados de liquidación. Como profesor, quiero ver mi listado de clases liquidadas en un periodo. Es decir, tendré filtros de fecha de inicio y fin (por defecto: desde en blanco, hasta el fin del mes anterior) y un listado, que incluirá todas las clases impartidas por mi en ese periodo y que han sido liquidadas. Para cada clase se incluirán los detalles básicos: nombre de la edición, fecha, hora de inicio y fin, fecha y hora de liquidación.;F;4;4;
630;[Aula Virtual] Estilos cámaras de video / imágenes de los participantes. * La cámara del usuario conectado debería verse siempre en la zona baja de la pantalla. Ya se ve en grande (con la clase focused), y los botones le servirán para encender/apagar la cámara. * El resto de cámaras deberían ajustarse a los prototipos iniciales: si hay 2 cámaras, deberían verse en grande, y a partir de 3 cámaras se hace un mosaico de 4 huecos, habiendo sitio en total para 8 cámaras (2 cuadros de 4 cámaras), aparte de la del propio usuario.;US;1;3;
624;"[Gestión] Cambios en menús de administración. - Menú docencia:   - ""Productos""   - ""Ediciones""   - ""Programar pruebas de nivel"" (levelTestRequests)   - ""Programar grupos"" (registrationRequests)    ------ (separador)   - ""Clases""   - ""Evaluacioes de clases""  - Menú de gestión de usuarios: - Quitar todos los ""Listado de "". En su lugar, poner ""Perfil XXXX"" - Menú de estudiantes: quitar ""Listado"" / ""Lista de"" de los nombres: será - Menú profesores se renombra a ""Profesorado"". Los submenús se renombran a ""Candidato"" ""Registrado""  - Ojo! En los menús en los que se quite ""Listado de ""/""lista"" hay que duplicar los mensajes, para cambiar el menú pero mantener al entrar en la página el texto ""Listado de XXXX"" en el título que se muestra encima de la tabla";LF;4;3;
623;[Gestión] Múltiples peticiones en detalle de un curso. Como profesor, dentro del detalle de uno de sus cursos se están haciendo dos peticiones cada vez que se cambia la paginación. Además, no lo he visto a fondo, pero se están obteniendo otra vez los alumnos cuando se cambia la paginación de las lectures, lo cuál creo que no es necesario.;F;4;4;
620;[Aula Virtual] Ver fotos de los participantes cuando no tienen la cámara encendida. ;F;3;3;
610;[Gestión] Como administrador, quiero ver el histórico de valoraciones (de supervisor) de cualquier profesor. Propongo añadir una entrada nueva en el menú lateral de profesores, que solo estará disponible para un administrador, y que mostrará las evaluaciones recibidas por el profesor por parte de su(s) supervisor(es). La página mostrará un listado de evaluaciones, con datos básicos: Fecha, supervisor y comentarios. Las ordenaría por fecha por defecto, de más recientes a más antiguas. Es de esperar que el listado sea tan corto que nunca sea necesaria la paginación, por lo que podríamos usar un listado en vez de una tabla paginada, pero creo que podemos mantener la tabla paginada para mantener la consistencia con la pestaña de feedback de los estudiantes.;F;3;4;
609;[Gestión] Panel de control de alumno v2.  Tareas pendientes asignadas. Cada clase mostrada debería verse en formato tarjeta, con toda la información, al estilo de las tarjetas del panel de control de administrador o similar. Idealmente deberían caber varias entradas en paralelo. Además, hay que considerar las pruebas de nivel como un curso más, es decir, también hay que mostrar la próxima clase de prueba de nivel asociada.  ;F;2;3;
604;[Gestión] Tamaño por defecto de los listados paginados. - Cambiar el tamaño de la paginación por defecto a 100 en todas las tablas paginadas. ;US;3;3;
604-2;[Gestión] Tamaño por defecto de los listados paginados. Cambiar las opciones de paginación en todas las tablas paginadas: [10,100,-1]  (no se si es posible configurarlo de forma global, entiendo que no sin extender v-data-table, pero al menos sería útil tener el array con las opciones en un único punto en lugar de repetir la lista de valores en todos los componentes).;US;3;3;
603;[Gestión] Cambios en panel de control de admin. El componente de listado de mensajes en el panel de control debería llevar un título y un borde/padding.  Además, ponerlo en la parte derecha de la pantalla.  (la colocación y los estilos se replicarán en los paneles de control de todos los perfiles)  Además se añadirán las siguientes fichas/contadores panel de control:   - Estudiantes candidatos       (número total y enlace al listado correspondiente, que ya existe)   - Profesores candidatos       (número total y enlace al listado correspondiente, que ya existe)   - Niveles de profesor pendientes de aprobación (TeacherLevel en estado PENDING, enlace a un listado a crear)   - Referencias de profesor pendientes de enviar (References en estado PRELIMINARY, enlace a un listado a crear)  Listados nuevos a crear (accesibles desde los nuevos indicadores): - Lista de niveles pendientes de aprobación: mostrar nombre del profesor, que será un enlace a la sección de educación/niveles de su perfil, nivel solicitado, y botones para aprobar/denegar (igual que puede hacerse en su perfil) - Lista de referencias de profesor pendientes de enviar: mostrar nombre del profesor, que será un enlace a la sección de referencias de su perfil, datos básicos de la referencia y botones de enviar (igual que puede hacerse entrando en las referencias del profesor);F;3;3;
602;[Gestión] Añadir alerta de mensajes nuevos al icono de mensajería. Destacar el icono de mensajería cuando haya mensajes nuevos en cualquier canal.   Propuesta: mostrar el número de mensajes en rojo, en una esquina por encima del icono de mensaje (puede verse como los números de las fichas en el panel de control del administrador);LF;3;3;
600;"[Gestión] Liquidación de clases de profesorado. En la vista de clases de profesores necesitamos hacer algunos cambios:  - El número que se mostrará será el número de clases impartidas y no liquidadas (pagadas), en lugar de solo las no impartidas - Los filtros por defecto serán: desde en blanco, hasta el último día del mes pasado  Añadir un botón para ""Liquidar selección"" en la parte superior. Este botón hará lo siguiente: - Recuperar la lista de clases realizadas y no pagadas en el intervalo (debe recibir para esto todos los filtros de búsqueda y hacer la consulta) - Marcar todas las clases leídas como pagadas - Generar un documento PDF que contenga un informe de liquidación. La idea es que contenga una página por profesor (si resulta más simple puede generarse una única plantilla con Jasper, para un profesor, y repetir la generación tantas veces como profesores haya. Después pueden concatenarse los PDFs o generar un ZIP con todos ellos). El contenido del documento será:   - Un título que diga algo como ""Liquidación de clases""   - Una cabecera con la fecha actual, los intervalos de clase seleccionados y los datos básicos del profesor (nombre completo, email)   - Una tabla que mostrará los detalles de todas las clases liquidadas, incluyendo para cada una: nombre del curso (edition.product.title, o ""Prueba de nivel"" si es una prueba de nivel), fecha, hora de inicio y fin, número de estudiantes.   - Un resumen al final que indicará el total de clases liquidadas. Algo como ""Total de clases liquidadas en el periodo: XXXX""    La plantilla del informe puede ser muy básica, se mejorará más adelante junto con otros documentos ya generados con Jasper";F;4;4;
598;"[Gestión] Cambios en gestión económica. Cambiar menú a ""Gestión económica""  Cambiar textos de entradas de menú: - ""Estado monederos"" / ""Wallets status"" - ""Liquidación profesorado"" / ""Staff settlement"" - ""Facturación"" / ""Billing""  ";LF;4;3;
598-2;"[Gestión] Cambios en gestión económica. En listado de facturas: - Añadir enlace para descargar PDF (depende de generación de PDF) - Añadir enlace global para descargar PDF de todas las facturas que pasen los filtros (similar al botón de ""exportar a XML"" pero generará un ZIP con un documento por factura. Utilizar ""serie/codigo.pdf"" como número de factura (por ejemplo, ""LEMSI/0001.pdf""";F;4;3;
594;[Contenido] Separar las actividades tipo link del resto de actividades. La lista BIBLIOTECA MULTIMEDIA mostrará solo las actividades tipo link y LISTA DE ACTIVIDADES mostrará el resto. A BIBLIOTECA MULTIMEDIA tienen acceso todos los alumnos en cualquier momento.;F;3;3;
593;[Contenido] Añadir filtro por WORDS en las listas de actividades. ;F;2;3;
592;[Gestión] Impedir acceder a formularios de registro estando logueado. Si yo me encuentro logueado y accedo a una ruta de registro (http://localhost:9001/account/company/create , http://localhost:9001/account/register), puedo registrarme sin problema ninguno (no debería poder acceder a estas rutas un usuario registrado).;SE;1;3;
590;"[Gestión] Exportar datos de factura a XML. Necesitamos poder exportar a formato XML los datos de las facturas generadas en el sistema   Se integrará en el listado de facturas del administrador, donde podemos tener dos acciones: - <s>Al lado de cada factura, un icono ""generar XML"".</s> (Probablemente no tiene sentido hacerlo por factura individual.) - En la parte superior, un botón ""exportar XML"" que exportará a XML todas las facturas que encajen con el filtro de búsqueda actual.   La exportación tendrá que descargar un zip con dos XML, factura.xml y lineaFactura.xml (el primero contiene los totales de cada factura y el segundo el detalle de las líneas individuales de factura, en este caso se generarían las mismas dos líneas de factura que en el PDF).  EDIT: Añadidos XMLs mínimos con posibles valores a incluir en cada campo ";F;3;3;
580;[Contenido] Añadir filtro por tipo de contenido en Media List. Filtro que permita mostrar solo pdfs, imágenes, links, etc.;F;3;3;
578;"[Aula Virtual] Mover botón para ""unirse"" a la primary toolbar. ";LF;4;3;
577;"[Gestión] Mejoras en canales de mensajería. - Los canales de notificaciones deberían ser de solo lectura (el usuario no puede escribir). Entiendo que puede controlarse por el tipo de canal en el cliente. - Controlar creación de canales duplicados (se da para un tutor y un profesor): al menos para los canales de comunicación uno a uno, revisar que no exista otro canal del mismo tipo con los mismos participantes (podría tener sentido tener canales duplicados para ediciones diferentes). - Aplicar títulos más indicativos a los canales, en particular para los de notificaciones (un tutor puede estar en varios canales de notificaciones, por ejemplo, al estar en los de sus alumnos). - Hay que incorporar un mecanismo para ""dar de baja"" a un usuario en un canal. Entiendo que puede hacerse indicando una fecha de fin en UserChannel, y habría que modificar el código para que un usuario solo pueda ver los mensajes entre su fecha de entrada y la fecha de salida. Entiendo que lo más cómodo es simplemente filtrar los métodos de consulta, pero también sería útil por seguridad asegurarse de que los mensajes enviados a un canal solo tienen como destinatarios a los usuarios que están de alta ahora mismo en el canal. El objetivo final de este cambio es poder quitar a un usuario de un canal, para que no pueda escribir en el ni ver mensajes nuevos, pero que no pierda el acceso a los mensajes antiguos. - También habrá casos en los que queramos ""dar de baja"" un canal completo. Esto sería convertirlo en un canal de solo lectura para todos los usuarios. Aunque puede hacerse simplemente ""dando de baja"" a todos los usuarios, puede resultar más práctico añadir un atributo adicional para comprobarlo en el canal directamente, por si pueden mostrarse al final en el listado o de forma diferente.  Casos a tener en cuenta en los que hay que procesar bajas (si lleva mucho tiempo considerar todos los casos a continuación en esta issue, puede mergearse solo el comportamiento base anterior e incorporar los casos particulares a una nueva issue): - Cuando un jefe de estudios deja de supervisar a un profesor, hay que dar de baja el canal (no pueden comunicarse ya por este canal, pero deberían conservarse los mensajes antiguos y podrían acceder a ellos). - Cuando un usuario se da de baja, podemos hay que eliminarlo de cualquier canal grupal (dar de baja su canal con los administradores, con sus supervisores si era profesor, con sus profesores supervisados si era jefe de estudios) y darlo de baja a el en sus canales de clases/cursos, los canales de su alumno si era tutor, la sala de profesores si era profesor). Revisar si se puede estar escapando alguna otra opción de canal.   - Cuando un tutor deja de ser tutor de un alumno, hay que darlo de baja de todos los canales del alumno. - Cuando un estudiante se da de baja de un curso, hay que darlo de baja de los canales propios del curso.  (Probablemente existan otros casos, que se considerarán en otras issues en el futuro)";F;3;2;
574;[Aula Virtual] Buscador de actividades. , debería añadirse un buscador de actividades para no tener el listado de todas.;F;1;3;
573;[Aula Virtual] Cambiar lista de actividades a añadir. Ahora mismo esa lista es muy cutre, directamente sobre el cuerpo del componente de classroom. Debería aparecer en un listado similar al de los participantes.;F;1;3;
572;"[Aula Virtual] Vista para cambiar los dispositivos utilizados. El botón de ""settings"" debería mostrar una modal o algo así para cambiar los dispositivos utilizados, algo similar a la preview. De hecho, igual se podría usar la misma vista como preview.";F;2;3;
557;"[Gestión] Panel de control del jefe de estudios. Cambios en el jefe de estudios: - Si un usuario tiene los roles de jefe de estudios y profesor, no se le dará la opción de escoger ""Profesor"", verá siempre el menú de jefe de estudios. ";SE;2;3;
557-2;"[Gestión] Panel de control del jefe de estudios. En el panel de control de un jefe de estudios, este verá:   - Notificaciones a la izquierda   - Sus datos como profesor   - Para cada profesor que supervise, una ficha con la próxima clase de ese profesor, que permitirá ver el detalle y unirse al aula virtual. Además, añadir un enlace en algún punto para acceder a la vista existente de todas las ""close lectures"" de ese profesor.";F;2;3;
556;"[Gestión] Panel de control de profesor.   Un profesor tendrá en su página de inicio un panel de control con sus notificaciones y sus próximas clases por curso. Esto implica - Para cada curso, verá su próxima clase, con los detalles básicos y botones de unirse - Para las pruebas de nivel, verá la próxima (con un caso particular: si hay varias hoy, debería verlas todas; por generalizar podemos programar el comportamiento de que, si hubiese varias pruebas de nivel el mismo día, sea cual sea, se devuelven todas).";F;2;3;
555;[Gestión] Panel de control de gestores de contenido.  En la página de inicio de un gestor de contenidos, verá un panel de control con la siguiente información: - Parte izquierda: notificaciones desplegadas - Botones a definir;F;1;3;
554;[Gestión] Panel de control de un tutor.  La página de inicio de un tutor le mostrará un panel de control con la siguiente información - Parte izquierda: notificaciones desplegadas - Información del monedero:   - Su saldo   - Para cada estudiante asociado, nombre, saldo y siguiente cobro previsto  - Información de clases:   - Para cada estudiante asociado, su detalle de clases próximas (el mismo detalle que ve el propio alumno en su panel);F;2;3;
553;"[Gestión] Panel de control de alumno.   La página de inicio de un estudiante será un panel de control con la siguiente información: - En la parte izquierda, las notificaciones desplegadas (ver #552) - Saldo del monedero (si es mayor de edad) - Próximo cobro previsto (fecha e importe)(si es mayor de edad): hay que calcularlo, de la misma forma que se estima el día 25 (`RegistrationServiceImpl.checkUserWallets`); la fecha siempre será a final de mes - Próximas clases, por curso: para cada curso (edición) en la que esté el estudiante, se mostrará una pequeña ficha que indicará los siguientes datos de la próxima clase a la que tiene que asistir en ese curso:   - Nombre del curso (edition.product.name)   - Fecha y hora de la clase   - Profesor   - Enlace para ver el detalle de la clase y para unirse al aula virtual (con las mismas comprobaciones que el resto de listados, es decir, solo si está en el estado y rango temporal adecuado).   - Tareas pendientes asignadas (deberes, depende de #524) Cada clase mostrada debería verse en formato tarjeta, con toda la información, al estilo de las tarjetas del panel de control de administador o similar. Idealmente deberían caber varias entradas en paralelo. Además, hay que considerar las pruebas de nivel como un curso más, es decir, también hay que mostrar la próxima clase de prueba de nivel asociada.";F;2;3;
552;[Gestión] Añadir vista de notificaciones desplegadas al panel de control del administrador. En el panel de control del administrador debería mostrarse, ocupando toda la parte izquierda de la pantalla, el listado de notificaciones. El resto del contenido del panel de control se dejará como está, pero se ubicará a la derecha de este listado de notificaciones.  La vista de notificaciones no será flotante. No sé si es sencillo parametrizar la vista flotante que ya existe para reutilizarla como elemento fijo, si no es así puede duplicarse. La idea es que podamos integrar ese componente (lista de notificaciones ocupando todo el alto disponible) al menos en la página de inicio de otros usuarios (se hará en otras issues, pero es importante mantenerlo como un componente reutilizable fácilmente);US;4;4;
548;[Contenidos] Ocultar en los resultados de actividades la columna de tiempo. Actualmente no se está guardando el tiempo invertido en cada actividad, por lo que la columna quedar en blanco.;F;3;3;
547;[Aula Virtual] Enviar siempre un display name incluso aunque el usuario no tenga. ;F;4;3;
545;[Aula Virtual] Botón de mostrar solo webcams debería manejarlo únicamente el profesor. ;F;3;3;
532;[Gestión] Dar de baja a un estudiante a fin de mes si no tiene saldo para pagar sus matrículas. En la comprobación del día 25 de mes se avisa a un estudiante de que no tiene saldo suficiente (Esto es correcto) En la comprobación a final de mes (RegistrationServiceImpl.generateNextMonthPayments) ahora mismo se le avisa de nuevo. El comportamiento a implementar es: - Añadir un aviso diferente, que diga que no tenía saldo suficiente por lo que se le ha dado de baja de sus cursos. Enviar el aviso también al administrador (depende de #527) - Dar de baja las matrículas (establecer estado INACTIVE) - Si quedan otros alumnos en la edición: borrar sus attendances para todas las lectures futuras. - Si no quedan otros alumnos en la edición: borrar las lectures futuras y enviar una notificación al profesor indicando que el curso se ha cancelado.;F;3;3;
531;[Gestión] Acceso público a la lista de productos y detalle básico.. La actual lista de productos (Product List) que ve el estudiante, y el detalle al que se accede pinchando en cada una (detalle del producto y detalle del curso) tendrán acceso público. - Revisar los permisos;F;3;3;
531-2;"[Gestión] Realizar algunas modificaciones en el comportamiento y menús: - Añadir un menú nuevo (""Available courses"") que se desplegará en una entrada para cada idioma (inglés, chino, español). Cada una de las entradas llevará al listado de productos filtrado para el idioma indicado. Este menú nuevo estará disponible para usuarios no registrados y para estudiantes. Este menú reemplazará al actual ""Teaching-> Product List"" de los estudiantes, que se puede eliminar. - Entiendo que podemos añadir el idioma en la URL y usarlo directamente, o añadir un selector de idioma a la vista; en cualquiera de los dos casos, el selector de nivel debe mostrar solo las opciones del idioma seleccionado. - Revisar las acciones disponibles: las opciones de matricularse no estarán visibles para usuarios no autenticados.";LF;3;4;
527;"[Gestión] Cambios en canales de mensajería básicos de usuario. Ahora mismo hay usuarios que no tienen canales de mensajería pre-creados. Son los que tienen perfiles CONTENT_EDITOR y ADMIN. Además, el funcionamiento de los canales ""con el administrador"" no es correcto, ya que puede haber varios usuarios de tipo administrador.   Cambios a realizar:  - Definir los métodos en ChatroomService para definir los canales por defecto de un content editor y un admin   - CONTENT_EDITOR: crearle un canal con administrador y notificaciones, igual que al resto de usuarios del sistema (el usuario se crea en `UMUserService.createBasicUser`, puede determinarse el rol a partir de `authoritySelected`)   - ADMIN: Tendrá un canal de notificaciones propio. Además:      - Añadirlo al canal de ""notificaciones de administrador"" (debería ser un canal de notificaciones donde estén todos los administradores)      - Añadirlo a los ""canales de administrador"" de todos los usuarios del sistema que lo tengan. - Modificar data.sql para que todos los usuarios precreados en el sistema tengan los mismos canales que se les generarían si fuesen creados desde cero:   - admin: canal de notificaciones propio, notificaciones de administrador y canal de comunicación con todos los demás usuarios   - resto de usuarios:     - canal de notificaciones propio     - canal de comunicaciones con administradores   - tutor1: además de sus canales propios, añadirlo al canal de notificaciones de su estudiante  Quedarían pendientes para otra issue los canales asociados a ediciones de cursos/clases/estudiante-profesor, que aún no se están creando automáticamente.";F;4;3;
525;"[Gestión] Limitaciones para darse de baja en un curso. Cuando un alumno solicita una baja en un curso, debemos añadir los siguientes controles/avisos - Si estamos entre los días 1 y 25 del mes, debería mostrarse un aviso indicando que las clases del mes en curso no son reembolsables. Se pondrá por defecto como fecha de baja solicitada el último día del mes actual, pero podrá cambiarse a cualquier día posterior a la fecha de hoy (es decir, puede solicitar la baja para mañana, aunque queden 10 días del mes, pero no se le devuelve el dinero). - Si estamos en un día posterior al 25 del mes, debería mostrarse en la modal una alerta indicando que las solicitudes de baja deben indicarse antes del 25 del mes, por lo que se cobrará en cualquier caso el mes siguiente. La fecha de baja se establecerá por defecto al último día del mes próximo, pero podrá cambiarse a cualquier fecha a partir del día 1 del mes próximo (ejemplo: hoy 29 de septiembre me avisa de que no estoy en plazo, y me pondrá el 31 de octubre como fecha de baja solicitada; puedo cambiarla al 15 de octubre, o al 1 de octubre, y se guardará sin problemas; si la cambio para el 30 de septiembre no me permitirá guardar la solicitud; tampoco podré dejar el campo en blanco en este caso)";F;2;3;
524;[Contenidos] DEBERES: Como alumno, quiero realizar actividades H5P fuera de la clase. Como alumno, en la pestaña RESULTS (habrá que buscar un nombre mejor) quiero que me salgan dos tablas: 1. Actividades pendientes (vacías y con fecha límite). 2. Actividades ya hechas con mis resultados (como ya está ahora).;F;1;4;
522;[Contenidos] Como alumno quiero subir un pdf con el ejercicio resuelto en el marco de una actividad. ;F;4;4;
521;"[Gestión] Listado y exportación de facturas. Como administrador, debería tener una entrada de menú ""Facturas"" dentro del menú ""Economic management"". Esta entrada llevará a un listado de facturas, con las siguientes funcionalidades:  - Se mostrará un listado paginado de Invoices. Para cada una, se mostrará el código, el nombre del usuario, la fecha y el estado. Además:   - El nombre de la persona será un enlace al monedero del usuario.   - En la parte derecha habrá un icono de PDF para obtener el PDF de la factura (a realizar en otra issue) - La página debe incluir los siguientes filtros:   - Filtros de fechas ""desde"" y ""hasta"". Los valores por defecto de estos filtros serán el mes anterior completo (es decir, si accedo a la página por defecto se mostrarán los datos del mes anterior por defecto, aunque en estos filtros se podrá cambiar).   - Filtro por usuario (permitirá escoger de entre los UserData que tienen algunha factura asociada)";F;4;4;
520;[Gestión] Asociar nivel a un estudiante. 1) El selector de niveles te permite escoger entre niveles de todos los idiomas: debería dejar escoger entre los posibles niveles asociados al idioma para el cual se realiza la prueba de nivel.  2) Una vez se escoge uno de los niveles del selector, y se acepta, salta error interno.;F;1;3;
511;[Gestión] Pruebas de nivel. En relación a las pruebas de nivel:  1) Se permite establecer una prueba de nivel en un tiempo ya pasado (p.ej. si entro ahora puedo programar una prueba de nivel para hoy por la mañana, algo que no puede ocurrir).  2) El botón para eliminar una prueba de nivel lo haría de doble comprobación (como otros de este tipo que ya existen)  3) Sugerencia: los nombres escogidos para los botones correspondientes a la solicitud de una prueba de nivel y la realización del cuestionario de evaluación previo no son muy intuitivos. Quizás pondría en algún lado un texto explicativo indicando que primero es necesario realizar el test previo antes de solicitar una prueba de nivel. También su colocación en la página haría que fuese otra para que de alguna forma se intuyese qué es lo que hay que hacer primero.;US;3;4;
509;[Gestión] Notificaciones al tutor. Cuando se envía una notificación (ChatroomService.sendNotification) a un estudiante, si el estudiante es menor, debería enviarse exactamente la misma notificación a sus tutores (a los que estén registrados en el sistema).;F;3;3;
506;[Contenidos] Añadir búsqueda en los listados de palabras. En la vista de formulario y detalle de una wordlist, aparece un listado de palabras asociadas a esta. Habría que añadir un recuadro de búsqueda para facilitarle al usuario encontrar determinadas palabras (simplemente una búsqueda por texto).  ;F;3;3;
505;[Aula Virtual] Integración de visor de PDFs con el aula virtual. ;F;3;3;
504;"[Aula Virtual] Botón ""finalizar clase"". El profesor tiene un botón para finalizar la clase. Podemos hacer que al darle a salir le aparezca una modal para elegir si solo quiere salir o si quiere finalizar. Igual en vez de una modal podría ser un botón como el de teams de ""terminar reunión"".  Finalizar echa a todo el mundo, setea la hora de finalización de la clase, cambia el esatdo de la misma, y todo lo que se supone que pase al finalizar una lecture.";F;1;2;
497;[Contenidos] Como alumno registrado, quiero ver los resultados de las actividades que he realizado en una lecture al entrar en la vista de detalle de esa lecture. ;F;4;4;
494;"[Gestion] Securizar endpoints de Teacher y Student. Estos dos servicios (*TeacherServiceImpl* y *StudentServiceImpl*) no tienen gran parte de sus métodos anotados con ""PreAuthorized"", habría que ir haciéndolo.";SE;4;3;
493;"[Gestión] Mejoras en la vista de detalle de una lecture. En la vista de detalle de una lecture debería poder verse: - Una indicación de a que se corresponde (""Prueba de nivel"" y el idioma, si es una prueba de nivel, o el nombre del producto si es una clase normal.";F;3;3;
492;[Gestión-Aula virtual] Controles para el acceso al aula virtual. Solo se podrá acceder al aula virtual si la clase está en estado PLANNED o DOING (los botones son accesibles desde el listado de lectures o desde el detalle de una lecture);SE;3;2;
490;[Gestión] Como administrador, quiero anular una clase. Desde la vista de detalle de una clase, como administrador, quiero poder anularla.  Esto implica: - Cambiar el estado de la clase a CANCELLED - Enviar una notificación al profesor y los estudiantes;F;4;4;
488;"[Gestión] Modificaciones en formularios de registro.  - Añadir un atributo ""acceptRGPD"" y un ""acceptCommercialCommunications"" a UserData (booleanos) - Añadir un atributo ""acceptCV"" a Teacher (solo lo tendrán los profesores)  - Modificar las pantallas de registro inicial (estudiante, profesor), de registro como tutor y de registro de compañía para incorporar:    - El checkbox de LOPD al final    - Textos legales, justo debajo del check de LOPD (usaremos el modelo ""compacto"" que se muestra en este documento: [doc](https://gitlab.lbd.org.es/lms4.0/docs/-/blob/master/DocumentosInterculturas/20210930-LOPD/Protecci%C3%B3n%20de%20datos_CITIC.docx)) (hay variante para profesor y estudiante, pero solo difieren en la finalidad principal. Para compañías y tutores usaremos el mismo modelo de los estudiantes.    - El checkbox de comunicaciones comerciales encima/debajo del de LOPD  Además, en la pantalla de registro como profesor debe aparecer la siguiente indicación:  ""AVISO: acepto subir mis datos/CV, hasta que cause baja voluntaria o cause baja automática según el periodo máximo legal establecido"" (con un check ""Acepto"", que si no se marca impedirá registrarse, asociado a ""acceptCV"")  El comportamiento es: si no se marca el check de LOPD (y acceptCV si es profesor) no se puede completar el registro, por lo que no se puede entrar. El check de comunicaciones comerciales puede dejarse desmarcado y no afectará al proceso. Cuando un admin de de alta a una persona, los valores por defecto serán ""true"" para los obligatorios y ""false"" para las comunicaciones comerciales.  El campo acceptRGPD no será editable en ningún formulario de perfil. Hay que verificar que no se pierda/sobreescriba el valor al editar otros datos del perfil. El campo ""acceptCommercialCommunications"" sí será editable.  NOTA: añadir en src/main/resources/data un archivo con la sentencia update que garantice que los datos antiguos se pueden actualizar valores adecuados (además hay que modificar el data.sql, como siempre)";F;1;4;
487;[Gestión] Listado y perfil de empresas. Crear los accesos al propio perfil y los listados de administración para empresas, de la misma forma que para el resto de roles. En principio implica:  - Como administrador, quiero ver un listado de empresas de alta, con sus datos básicos. Quiero darlas de baja. (puede crearse un menú nuevo de admin para este listado) - Como empresa, quiero ver/editar mis datos de perfil. Como administrador, lo mismo sobre cualquier compañía.    - Crear barra lateral y controlar los permisos (propio o admin)   - Crear vista de detalle y de edición de perfil, controlando los permisos (propio o admin)   - Botón de cambiar contraseña (solo perfil propio);SE;3;4;
482;[Gestión] Panel de control para administradores. La página principal de un administrador debe ser un panel de control que incluirá indicadores numéricos y enlaces a los listados de trabajo principales.   En la primera versión, vamos a incluir los tres listados de revisión que hay ahora mismo: - Solicitudes de pruebas de nivel (mostrar el número de solicitudes en estado pendiente, el número redirige al listado correspondiente) - Solicitudes de matrícula (idem) - Valoraciones de clases (idem);F;3;4;
481;"[Gestión] Como empresa, quiero solicitar la matrícula de mis usuarios en un curso. Como usuario empresa, tendré acceso a la lista de productos (añadir el menú y configurar los permisos). Desde esa lista, podré acceder a la funcionalidad de ""solicitar matrícula"" con un conjunto de controles y comportamientos diferente del de los usuarios normales:  - Una empresa solo puede solicitar productos de tipo curso, con fecha de inicio y de fin fijadas. - Cuando una empresa solicita un producto, puede indicar, además de los campos normales, la siguiente información, que se asociará a su ProductRequest:   - Una lista de usuarios (de entre los que tiene vinculados)   - Un conjunto de horarios - Para guardar la ProductRequest se comprobarán los saldos de los monederos de los usuarios, pero no los niveles o las disponibilidades que tengan. - Cuando un administrador revisa una ProductRequest de una empresa:   - No tiene que seleccionar usuarios (son los indicados en la ProductRequest)   - No tiene que seleccionar horarios (son los indicados en la ProductRequest)   - Tiene que seleccionar un profesor que tenga horarios compatibles con los indicados en la ProductRequest   - Se comprobarán los saldos de los usuarios pero no las disponibilidades.  En principio los procesos automáticos no cambiarían: el saldo se extrae de los usuarios mes a mes; nunca será necesario extender clases al ser de tipo producto, por lo que no hay problema por las disponibilidades.  EDIT: Cuando se programe la edición, debería guardarse una indicación de que está asociada a la empresa que la ha solicitado. Puede hacerse vinculando la edición en general con un ProductRequest, de forma que sería información disponible para todas las ediciones. Si esto supone algún problema comentarlo, puede hacerse también de forma específica vinculando la Edition con la Company en el proceso de matrícula.";F;2;4;
480;"[Gestión] Como empresa, quiero ""dar de alta"" un listado de usuarios. Como usuario empresa, desde el listado de usuarios asociados (#479), tendré un botón ""añadir usuarios"" que me permitirá indicar un listado de usuarios a dar de alta. El comportamiento será el siguiente:  - Debería aparecer un formulario en el que indicar un listado de nombres e emails (serán objetos StudentCompany sin Student asociado) - En el servidor:   - Se generarán los objetos correspondientes y una clave para cada uno de ellos.   - Se enviará un email a cada usuario, proporcionando un enlace que permitirá vincular su usuario con la empresa, si ya lo tiene, y una redirección a la página de registro para que se registre si no tiene usuario.   - El proceso de enlace con la empresa será similar al de asociación de un tutor con un estudiante: tendrá que hacer login, y si tiene el rol estudiante, podrá confirmar el vínculo, asociando el Student correspondiente a StudentCompany y eliminando el atributo ""key"".";F;2;4;true
479;[Gestión] Como empresa, quiero ver los usuarios que tengo asociados. Como usuario de tipo empresa, tendré acceso a un listado de los usuarios que tengo vinculados. Esto será muy similar a lo que ve un tutor (sus alumnos vinculados). La idea es la siguiente:  - Veremos el listado de todas las asociaciones (StudentCompany) - El listado solo mostrará nombre, email y un icono indicando el estado: para aquellos elementos que tengan un Student asociado, se mostrará el nombre a mostrar del usuario, y un icono que aclare que está confirmado. Para aquellos elementos que no tengan Student, se mostrará el name indicado en StudentCompany, y un icono que aclare que no está confirmado. - Habrá un enlace asociado a cada entrada, que permitirá eliminar la vinculación. El comportamiento será el siguiente:   - Se borrará el objeto con la asociación   - Si tenía un Student asociado, se enviará una notificación (ChatroomService.sendNotification) no importante al usuario correspondiente que se ha eliminado esta vinculación.;F;2;4;
478;[Gestión] Como empresa, quiero gestionar mi monedero: recargar y transferir.  Los usuarios de tipo empresa tendrán un Wallet asociado, y podrán recargarlo y ver sus movimientos normalmente: - Añadir un menú Wallet para el rol - Añadir la vista.    - Debería poder reutilizarse sin problemas el componente BalanceDetail.vue, revisando los permisos de acceso por rol.   - La empresa puede realizar transferencias a los monederos de los usuarios que tiene asociados (también debería poder reutilizarse toda la parte vista cambiando los targets, y revisando los controles de roles en el servidor)   - (Solo si no supone mucho esfuerzo, entiendo que no) A la hora de transferir saldo a los usuarios, para una empresa deberíamos dar la opción de seleccionar transferir a múltiples usuarios (es decir, seleccionar varias personas en la modal, de forma que se ingrese el mismo saldo a cada uno de ellos);F;2;4;
476;"[Gestión] Listado de lectures para gestión económica. Como administrador, debería tener acceso a un listado simplificado de lectures donde poder realizar trámites económicos. Visualmente no será muy diferente del listado de lectures que hay en el menú Teaching, pero el comportamiento, las acciones y algunos filtros serán diferentes.  - La entrada estará accesible en el menú ""Economic management"" como ""Lecture payment"". - Se mostrarán solo las lectures en estado ""DONE"".  - Se mantienen los mismos filtros que hay en el listado de administrador en ""Teaching"" - Se mostrará un atributo adicional que indique si está pagada  (si la Lecture tiene un TeacherPayment asociado, está pagada) - Se mostrará la duración de la clase. - No se podrá acceder al detalle de la lecture desde este listado. - Se añadirá un botón ""mark as paid"" a cada fila que no esté pagada. Eso creará un TeacherPayment asociado (el importe puede dejarse en blanco de momento).";F;4;3;
475;"[Gestión] Como usuario, quiero descargar la factura de cada recarga que haya realizado. En la vista de movimientos de un monedero, para aquellos movimientos que sean de tipo recarga de saldo y que hayan sido realizados por el usuario actual, habrá un botón para descargar la factura en PDF.  Puede usarse como base el código de !475 para el formato de la plantilla (define un InvoiceService con un método que genera un PDF muy básico a partir de un id de invoice).  Puntos a ampliar y añadir: - Añadir el botón en la vista y el endpoint en el resource que proporcionen acceso a la funcionalidad. Solo estará disponible para las operaciones que tengan un Invoice asociado (deberían ser todas las recargas). - InvoiceService:   - Revisar el control de acceso    - Añadir el contenido de las líneas individuales de la factura:      - Una línea para formación (90% del importe original; ojo! si tenemos el importe con iva hay que calcular el importe base como: formationAmount/ ( (100 + formationVAT)/100.0) )      - Una línea para materiales (10% del importe original; de nuevo hay que calcular el importe base a partir del final)   - Formatear todos los números a 2 decimales   - Añadir el método de pago   - Revisar el formato de salida   - Reorganizar el código según sea necesario - JasperSoft Studio (para editar la plantilla): https://community.jaspersoft.com/project/jaspersoft-studio/releases   - En la medida en que sea sencillo, ajustar la plantilla (estilos y colocación de elementos) para que se estructure como [este ejemplo](https://gitlab.lbd.org.es/lms4.0/docs/-/blob/master/DocumentosInterculturas/20210930-Factura/Factura%20A219200050.pdf)     - Poner la info de interculturas arriba a la izquierda     - Poner la info de interculturas arriba en el centro     - Código de factura y fecha arriba a la izquierda. Añadir el ""número de cliente"" (por el momento podemos usar nuestro userdata.id)     - Las líneas de factura contendrán lo que nuestro modelo actual (base imponible, iva, total), pero podemos ajustar los estilos de la tabla.     - El pie de página con los totales tendrá que contener el desglose de IVA a la izquierda (una línea por tipo de IVA, indicando lo mismo que las líneas de arriba: base imponible, porcentaje de iva aplicable y total) y el total a la derecha. El resto de campos de la plantilla de interculturas no se incluirán.     - Podemos añadir en el fondo de la página el mismo aviso legal que en la plantilla de interculturas.   - Revisar los campos de datos de dirección del cliente y modificarlos si es necesario   - Revisar formatos de textos y fechas para que sean consistentes. Los totales numéricos deben estar formateados con 2 decimales.   Pendiente: revisar y analizar si debería incorporarse otra información relevante";F;2;4;
473;[Gestión] Canal de mensajería profesor/supervisor. Cuando se asocie un profesor con un jefe de estudios hay que crear un canal de mensajería asociado a ambos.;F;2;3;
472;[Gestión] Como estudiante, quiero ver mi valoración final en un curso. Un estudiante, una vez tenga una StudentFinalEvaluation para un curso, podrá verla entrando en los datos de dicha edición (a través de sus registrations). Tendrá los 3 campos indicados por el profesor (curso superado, puntuación y comentarios), así como un botón para descargar un certificado (a realizar en otra issue);F;3;4;
470;"[Gestión] Como profesor, quiero evaluar a los alumnos a la finalización de un curso. Desde la vista de detalle de una edición, en la tabla de estudiantes matriculados, un profesor podrá añadir una valoración global del estudiante en el curso (StudentFinalEvaluation). Trabajo a realizar:  - Cambios en el modelo:    - Añadir un booleano ""passed"" (apto) para indicar la superación del curso  - Interfaz:   - Mostrar una modal en la que el profesor podrá indicar los comentarios, la puntuación y si ha superado el curso. Para la superación del curso usar un select para forzar a que se escoja un valor, y hacer el campo obligatorio. Los otros dos campos no son obligatorios.  - Servidor:   - Se debe guardar una StudentFinalEvaluation con los datos correspondientes y enviar una notificación al estudiante indicando que su valoración final en el curso ha sido completada y que puede verla entrando en su matrícula.";F;3;4;
469;"[Gestión] Registro como empresa. Se añade un nuevo rol en el sistema: empresa (organización que puede tener estudiantes ""vinculados"" y solicitar formación para ellos).  Trabajo a realizar: - Definir el nuevo rol ROLE_COMPANY, con sus entradas de menú (por el momento solo datos de perfil) - Ajustes en el modelo de datos:   -  Una empresa tiene su propio nombre añadir atributo ""name"" a Company. De esta forma, los valores de ""name"" y ""surname"" en UserData serían datos del representante. - Crear el formulario de registro de una empresa. Creo que lo más rápido sería desarrollar una vista separada de la actual de registro, para evitar el problema de tener empresas invitadas que tengan que cubrir sus datos. Plantearía una vista similar a la de registro de tutor, donde hay que introducir todos los datos de golpe. La única diferencia con el registro de tutor sería que la empresa no se activa automaticamente, sino que se le envía el correo de activación al email. El formulario de registro sería similar al de un usuario normal pero con bastantes elementos recolocados, por lo que creo que es más sencillo hacer un componente independiente sin intentar reutilizar grandes bloques. Cambios relevantes: - Añadir el nombre como uno de los primeros datos, junto al display name. Etiquetar los campos de nombre y apellidos como datos del representante, para que quede claro que el resto de datos serían de la empresa. - Mostrar el campo NIF como CIF y eliminar el campo de fecha de expiración.  - Eliminar el campo de fecha de nacimiento. - Campos obligatorios: nombre de la empresa, nombre a mostrar, datos de dirección, nombre y apellidos del representante, cif, zona horaria, idioma (básicamente todos los mostrados)  Al cubrir el formulario se registrará el usuario como ROLE_COMPANY (no activado), creando el User/UserData/Company correspondientes, y se enviará el correo de activación.  (a realizar tras #463)";F;3;4;
468;[Gestión] Como jefe de estudios, quiero valorar una clase de un profesor que superviso. Como jefe de estudios, desde la vista de detalle de un profesor, quiero valorar al profesor en la clase. Esto implica añadir una nueva entidad al modelo de datos (TeacherSupervisorReview o similar) para guardar la valoración, que serán comentarios de texto. Los atributos de la entidad entiendo que serían:   - id   - lecture: Lecture (se supone que es al profesor de esa clase, puede añadirse también el teacher si resulta más práctico)   - supervisor: Teacher (para forzar que tenga que ser un teacher, también podría ser simplemente el UserData)   - date: LocalDateTime   - comments: String  Debería mostrarse un botón de valorar al lado de la info del profesor, y un popup en el que introducir los comentarios. Si ya ha sido valorado, debería tener alguna forma de ver la valoración guardada.  (depende de #467 y requiere nuevo modelo de datos);F;2;4;
467;"[Gestión] Como jefe de estudios, quiero ver el listado de clases de un profesor que superviso y entrar en cualquiera de ellas. Un profesor jefe de estudios debería tener un enlace para ver el listado de clases de un profesor que supervisa. Puede añadirse como un botón asociado a la información del profesor, en su pestaña ""Supervising"".  La visualización de la lista y del detalle será similar a la que tiene el propio profesor, incluidos los botones para acceder a la clase. Por defecto debería mostrar solo las clases de los días cercanos, como al profesor, pero le añadiría un check para mostrarlas todas";F;3;4;
465;"[Gestión] Como administrador, quiero cambiar el horario de una clase.  Desde la vista de detalle de una lecture, como administrador, debería tener la opción de cambiar el horario.  Comportamiento esperado: - El administrador pulsa en ""Cambiar horario"" (solo se permite si la clase está en estado PENDING) - El sistema recuperar la lista de horarios compatibles para los alumnos y el profesor de la clase. Para calcular esta lita puede reutilizarse el mismo código que se usa para programar las clases inicialmente. Este horario se muestra en un calendario, donde se podrá elegir solo de entre los slots válidos. - El administrador selecciona un horario, lo que envía la petición a servidor para crear un cambio de clase. - Enviar una notificación (chatroomservice.sendnotification) no importante al profesor y a los alumnos asociados a la clase, para indicarles el cambio de horario.";F;3;4;
464;"[Gestión] Como administrador, quiero poder cambiar el profesor de una clase. Desde la vista de detalle de una lecture, como administrador, debería tener la opción de cambiar el profesor.  Comportamiento esperado: - El administrador pulsa en ""Sustituir profesor"" (solo se permite si la clase está en estado PENDING) - El sistema recuperar la lista de profesores que podrían dar esta clase (exluir al profesor actual) y la muestra en un selector. Para calcular esta lita puede reutilizarse el mismo código que se usa para programar la clase inicialmente. - El administrador selecciona un profesor, lo que envía la petición a servidor para crear un cambio de clase. - Asociar el nuevo Teacher a la Lecture y establecer substitite=true.   - Enviar una notificación (chatroomservice.sendnotification) no importante al profesor nuevo, indicando que se le ha asignado una nueva clase.";F;4;4;
463;"[Data-model] Cambios en modelo de datos para usuarios de empresa. (generación del modelo de datos básico para avanzar con las nuevas funcionalidades de #462)  La idea es que vamos a tener usuarios compañía que podrán solicitar el registro de usuarios para que se vinculen con ella. Para ello mi propuesta es incluir:  - Nueva entidad ""Company"" que tendrá los siguientes atributos:   - id: Long   - userData: UserData   - List<StudentLink> students - Nueva entidad ""StudentLink"" que tendrá los siguientes atributos:   - id: Long   - company: Company   - key: String   - name: String   - email: String   - student:Student  StudentLink funcionaría como ""Tutor"": permite indicar los datos básicos de un estudiante y genera una clave, para que la persona acepte el link o no, de forma que duplica los datos mínimos de un estudiante. También podría quitarse el atributo ""student"" de StudentLink y añadir una List<Student> a Company, de forma que se crea el studentlink y al confirmarlo se crea por separado el link con el Student; así después sería más práctico acceder desde compañía a estudiantes y viceversa. Mantengo mi propuesta de forma similar a la parte de tutores por si facilita aprovechar el funcionamiento para este caso.  Además, una compañía va a poder configurar solicitudes de matrícula para alumnos y horarios fijos. Para ello sería necesario:  - Añadir a ProductRequest:   - company: Company (que solicita la matrícula)   - selectedStudents: List<Student>  (usuarios que se quiere matricular)   - schedules: List<AvailabilitySlot>  (horarios forzosos del curso) - AvailabilitySlot debe tener una forma de indicar el día de la semana y hora de inicio de una clase, creo que lo más práctico para despues hacer match con las disponibilidades de un profesor sería que el AvailabilitySlot tenga solo la referencia a la ProductRequest y a un TimeSlot";F;4;4;
446;"[Gestión] Vista global de las evaluaciones de una edición.  - Un profesor, desde la vista de una edición, puede ver la lista de evaluaciones públicas que ha recibido en esa edición (sería muy similar a la consulta que puede ver en su perfil, pero pre-filtrada para la edición concreta). importante: no ve todas las evaluaciones de la edición, solo ve las que se han hecho a clases impartidas por el (que deberían ser las que están asociadas a el como teacher) - Un administrador, desde la vista de detalle de una edición, puede ver todas las evaluaciones que se han realizado en esa edición (similar a la vista del profesor, pero incluye las no públicas, y debería mostrarse por lo tanto el estado de la evaluación; además, sería útil tener la indicación de la clase asociada y el profesor que la impartió)";F;3;4;
445;"[Gestión] Listado de ediciones para un administrador. Añadir un listado de ediciones en el menú teaching del administrador.  Características:  - Opción de filtrar por nombre (del producto), profesor, alumno - Acceso a la vista de detalle (puede reutilizarse la vista que tiene el profesor en su tab ""Editions"")";F;4;3;
444;"[Gestión] Las valoraciones de profesores se convierten en valoraciones de clases. Lo que ahora eran ""TeacherEvaluation"", realizadas por un estudiante, deberían pasar a ser ""LectureEvaluation"". Las seguirán realizando los estudiantes, y pueden seguir asociadas a una attendance, pero:  - El atributo teacher en principio sobraría, pero como queremos filtrar las valoraciones que puede ver un profesor podemos mantenerlo. - Debería renombrarse todo a ""LectureEvaluation"" en cliente y servidor. No sé como de simple es esto con el refactor de intelliJ o similar.   Los comportamientos que ya existían y que hay que conservar son: - [Ya existía y en principio debería seguir funcionado igual] Un profesor podrá ver las evaluaciones públicas de las clases que ha impartido.  - [Ya existía y los cambios son mínimos] El administrador puede ver y hacer públicas o no las evaluaciones realizadas. Habría que cambiar el título de la página y del menú. (hay dos comportamientos/vistas nuevos que se añadirán en otra issue)";F;3;3;
443;"[Gestión] Generar automáticamente una factura al realizar una carga en el monedero.. Hay tres casos en los que un usuario puede recargar un monedero: - Un tutor puede cargar el suyo propio - Un estudiante adulto puede cargar el suyo propio - Un tutor puede cargar el monedero de un estudiante que supervisa.  Queremos realizar los siguientes cambios:  - Controlar que la persona que realice una recarga de monedero tenga cubiertos un conjunto de datos ""fiscales""   - Debe tener cubiertos su nombre y apellidos, nif, campos de dirección (campo dirección, localidad, código postal y país)   - Si no tiene esos datos cubiertos, no se le permitirá hacer la recarga. Aquí hay dos comprobaciones a realizar:     - (imprescindible) En el servidor, al intentar crear la operación de carga, se devolverá un error si no tiene los datos cubiertos. Esto debería hacerse en WalletServiceImpl.chargeWalletCommon.     - (recomendable) Si ya a la hora de mostrar los datos de un monedero (en BalanceTab.vue, tanto dentro de mockups/student como mockups/tutor) se recupera la información de si el usuario actual puede recargar el monedero (con una petición separada o añadiendo un atributo extra a WalletDTO), puede deshabilitarse el botón de carga y mostrar un aviso que indique ""Es necesario cumplimentar los siguientes datos de perfil para poder realizar recargas: XXXXX""    - Modificar la entidad Invoice de la siguiente forma:   - Eliminar el atributo ""code"" y añadir dos: un atributo ""series"" (String) y un atributo ""number"" (Integer)   - Añadir dos atributos: ""formationAmount"" y ""materialsAmount"", además del amount que ya existe, que pasará a ser el total   - Añadir dos atributos nuevos: ""formationVAT"" y ""materialsVAT"", (ivas para ambos importes anteriores)  - Crear automáticamente un Invoice cada vez que se haga una recarga de monedero:   - Esto se hará en el mismo momento en el que la recarga se confirme (es decir, cuando se actuliza el balance del monedero). Dependiendo del método de pago escogido, esto se hace en WalletServiceImpl.chargeWalletCommon o WalletServiceImpl.captureOrderCommon.   - Los campos del invoice se cubrirán como sigue:      - Se crea un Invoice asociado al usuario que hace la recarga (si un tutor carga el monedero de un estudiante la factura va a nombre del tutor), y con la fecha actual.      - El estado será pagada.      - El concepto no es relevante, puede ser siempre ""Recarga de monedero""      - Se asociará con el userdata correspondiente, y se copiarán del usuario al invoice los datos básicos (nombre y apellidos, campos de dirección y nif).      - El ""code"" será la descripción de la serie de facturación. Definir una constante, por el momento podemos usar ""LEMSI""      - El ""number"" tiene que calcularse para que sean números consecutivos. Para ello hay que recuperar de la base de datos el mayor número de factura asociada al mismo code que sea de este mismo año, y sumarle uno para generar esta. Si no hay ninguna factura que cumpla las condiciones (no hay facturas o es la primera del año), comenzaremos por 1.      - El ""amount"" total será el importe de la recarga.      - El amountFormation será amount*0.9      - El amountMaterials amount*0.1 (entre este y el anterior suman el total)      - El formationVAT será 21.0      - El MaterialsVAT será 4.0   (estos datos se usarán para generar un documento PDF, que se abordará en otra issue)";F;4;4;
442;[Contenidos] Integración de un visor de PDFs para permitir visualizar contenido multimedia dentro de la aplicación. ;F;3;3;
441;[Gestión] Cualquier profesor puede acceder a cualquier Lecture. Introduciendo manualmente la ruta de una lecture, cualquier profesor puede acceder a cualquier lecture. Habría que comprobar en servidor el usuario que está accediendo y devolver un 401 en caso de que no esté autorizado.;SE;3;3;
438;[Gestión] Como profesor, quiero ver el histórico de valoraciones de un alumno en un curso. Como profesor, debería tener la opción (icono/botón al lado de los datos de cada alumno, en la vista de detalle de una lecture) de ver el histórico de valoraciones que ha recibido el alumno en el curso (edition) actual. Deberían recuperarse todas las valoraciones del alumno y mostrarse, indicando la fecha, nombre del profesor que la ha hecho (al menos si no es el mismo que consulta, lo que podría darse en el futuro) y el texto de la valoración.;F;3;4;
435;[Contenidos] Como alumno registrado, quiero ver los resultados de las actividades que he realizado. ;F;3;4;
434;"[Gestión-contenidos] Mejoras en cuestionarios de prueba de nivel previos. - Controlar el acceso a un cuestionario:    - Mensaje en función del estado: ""Start"" si no se ha comenzado, ""Continue"" si está a medias, impedir el acceso si está completo.     (¿Hay forma de saber si está completo al 100%? Entiendo que solo si todas las actividades son H5P) - Modificar los mensajes para hacerlos consistentes con los de error de prueba de nivel. Lo llamaría ""cuestionario previo de nivel"", tanto en los botones de la pantalla como en el error que se muestra si se solicita una clase y no hay ninguno completo. - Actualizar el control que comprueba si se puede solicitar una prueba de nivel. Solo puede solicitarse si hay algún cuestionario completo (la comprobación actual es que haya alguno con alguna actividad completa, a falta de definir como funcionaría el control de completo)  EDIT: otras mejoras a considerar: mostrar el idioma del cuestionario en la lista.  ";F;4;3;
425;[Gestión-Contenidos] Guardar resultados de los cuestionarios de prueba de nivel. ;F;4;3;
410;[Gestión] Actualizar los datos de usuario en el cliente tras modificaciones del perfil. Al modificar los datos de perfil propios, se recarga la foto del usuario actual pero no se recargan otros datos, como el nombre por ejemplo, por lo que no se actualizan en el menú hasta el siguiente login. Debería forzarse una recarga de todos los datos en los mismos casos.;F;3;3;
409;"[Gestión] Botón UPDATE CV cuando ya se ha introducido un CV. Sustituir el botón ""ADD CV"", que aparece una vez un profesor ha añadido un CV, por ""UPDATE CV""";F;3;3;
408;[Gestión] Visualización del mes al modificar periodos de disponibilidad en el calendario. El hecho de tener que introducir cualquier modificación en el calendario sin poder visualizar en pantalla el mes, se hace sumamente complicado al tener que avanzar las semanas.;F;3;3;
407;[Gestión] Permitir que un jefe de estudios deje de serlo. Además de poder convertir a un profesor en jefe de estudios también se debe poder hacer que un profesor que era jefe de estudios deje de serlo.;F;3;4;
406;[Gestión] Permitir desvincular tutor desde un estudiante. El administrador puede vincular/desvincular estudiantes asociados a un tutor cuando accede a él, pero solo tiene la opción de vincular tutores cuando accede a un estudiante. Incluir también la funcionalidad de desvincular tutores desde los estudiantes.;F;3;3;
401;"[UI] Información del usuario consultado. Cuando un administrador accede a los datos de un usuario, o cuando un tutor accede a los datos de uno de los estudiantes que supervisa, no hay ninguna indicación de a qué persona está viendo/editando. Sería útil tener el nombre completo del usuario que se está consultando accesible (podría añadirse en la parte superior de la barra lateral que aparece con las entradas del usuario). Esto solo sería necesario si estoy accediendo a un usuario que no sea él mismo, por supuesto (es decir, si un tutor está en sus propios datos -perfil,monedero...-, no sería necesario que vea su nombre, pero si entró en un estudiante debería ver el nombre del estudiante; lo mismo para el admin).";US;3;4;
400;[Gestión] Controles para solicitar una clase de prueba de nivel. Un estudiante solo debería poder solicitar una clase de prueba de nivel si ha completado previamente las actividades de un cuestionario de prueba de nivel;F;3;3;
399;[Gestión] Mejoras en la programación de ediciones de cursos/clases a medida.  Al completar la programación de un curso de cualquier tipo, debería realizarse el cobro del mes actual (solo aplica si el curso comienza en el mes actual). Habría que calcular el importe a cobrar y realizar el cobro del monedero, de la misma forma que en #370.;F;3;3;
398;"[Gestión] Comprobaciones para solicitar la matrícula en un curso. Al solicitar la matrícula en un curso (Product), es necesario hacer las siguientes comprobaciones:  - El estudiante tiene que tener el nivel adecuado al producto, si este lo requiere (es decir, si es un curso de inglés B1, debería tener al menos el nivel anterior, A2, para poder matricularse). Si no lo tiene (o si no consta que tenga ningún nivel para el idioma), mostrarle un error. Mostraría dos mensajes diferentes: si no tiene ningún nivel asociado, decirle que necesita hacer una prueba de nivel antes de matricularse en ningún curso; si el nivel no es suficiente, decirle que el curso es demasiado avanzado - El estudiante tiene que tener saldo para pagar el primer mes del curso. Si no tiene saldo en el monedero, mostrarle un error indicándolo. El cálculo a realizar debería ser: si estamos antes del día 20, comprobar que puede pagar las clases de este mes; si no, comprobar que puede pagar el mes actual y el siguiente. Para calcular lo que tendría que pagar dependerá del tipo de producto: si se paga por clase (clases a medida) habría que contar las clases del mes; si se paga por mes (cursos), habría que comprobar el importe del mes (estos cálculos podrían reutilizarse/refactorizarse de #361).  Propuesta, como mejora al primer punto: puede ser útil añadir un filtro ""Sólo cursos en los que me puedo matricular"", que ya haga este filtro por niveles, de forma que por defecto no le salgan cursos que no puede hacer.";F;3;4;
389;[Gestión] Como administrador, quiero ver la estadística de clases impartidas por cada profesor. Entrando como administrador, en el menú de gestión económica, tendré una opción para ver las clases (Lectures) impartidas por los profesores. En esa página se mostrará un listado que incluirá filtros de búsqueda y un listado:  - Filtros: buscador por profesor (Teacher), y dos campos de fecha (desde y hasta) - Listado: mostrará, para cada profesor, su display name, nombre y apellidos y el número de clases que ha impartido dentro del rango indicado.  Servidor: - Definir un DTO (TeacherLectureCountDTO o similar) que incluya la información de cada fila. El total de clases puede almacenarse como un número, si queremos ver el listado detallado redirigiremos a otra pantalla que se resolverá en otra issue. - Definir un método en LectureResource que devuelva una List<TeacherLectureCountDTO> (también podría ser una Page<TeacherLectureCountDTO> si es más cómodo, pero en este caso no es necesario que la lista esté paginada). - Definir en el service el método que recupere el conteo de clases para cada profesor. El cálculo es el siguiente:   - El filtro de profesor se aplicará a lecture.teacher, forzando a que sea uno dado   - Los filtros de fechas (dateFrom y dateTo, por ejemplo) , se aplicarán a lecture.startTime y lecture.endTime, forzando a que tengan que estar en el rango dado   - Solo se tendrán en cuenta clases impartidas (lecture.state = DONE)  Cliente: - Definir la nueva entrada de menú - Definir el componente para el listado. Puede utilizarse cualquier otro listado del sistema como referencia. Para los filtros puede ser útil como referencia ProductList, por ejemplo (ruta /admin/products/product-list), que incluye filtros de fecha y de estudiante (puede hacerse algo muy similar por profesor)  (a completar detalles);F;4;4;
382;[Menú] Enlace a ruta no permitida para usuario no autenticado. Como usuario no autenticado, en el menú tengo la opción de ir a la página principal, aunque al clicar en el enlace sale un error en pantalla, al ser una ruta restringida a usuarios autenticados. Habría que, o bien eliminar el enlace, o que ese mismo enlace apunte a la página de login (solo en caso de usuarios no autenticados).;SE;3;3;
381;[Gestión] Como profesor registrado, quiero gestionar las actividades de una clase que imparto. Desde la vista de detalle de una Lecture, donde ahora mismo se ve la lista de alumnos y la lista de actividades, será necesario añadir la funcionalidad de añadir/quitar actividades a dicha lecture. Puede reutilizarse la interfaz/componentes usados para añadir actividades a una lesson en la sección de gestión de cursos.  Como parte de esta tarea pueden ocultarse también los campos que se incluían en la asociación actividad-lecture y actividad-lesson (duración, puntuación máxima) ya que no se utilizarán de momento. Realizar los mismos cambios en la asociación con lectures y en la asociación con lessons (será necesario probablemente modificar controles ya que algunos de los campos eran originalmente obligatorios)  ;F;4;4;
380;[Gestión] Lista de Lectures para el administrador. Añadir un acceso a la lista general de todas las clases del sistema, a la que podrá acceder un administrador. Ya existe un componente para verlas (LectureList), pero será necesario ampliarlo y controlar los permisos de acceso.  - Añadir los siguientes filtros:   - Profesor (selector autocompletado por nombre)   - Estudiante (selector autocompletado por nombre)   - Producto/Edición (selector autocompletado por nombre)   - Fecha (desde + hasta) para buscar por intervalos   - Estado (selector) - Modificar el detalle de la clase, al que se accede pinchando en cada fila, para que al acceder como administrador se pueda ver la información básica de los profesores y de los alumnos (el componente ahora mismo muestra diferentes detalles a estudiantes y profesores, un administrador básicamente verá tanto la información de los estudiantes como de los profesores).;F;4;4;
379;[Gestión] Como estudiante, quiero valorar a mi profesor al finalizar una clase.. Un estudiante puede valorar a su profesor al finalizar una clase (Lecture)  Propuesta de cambios:  - Añadir un botón para valorar al profesor en la vista de detalle de una lecture (LectureDetail, accesible desde el menú teaching->lectures->[entrar en una]). Este botón puede abrir una ventana modal en la que cubrir la valoración del profesor y guardarla. Esto creará la TeacherEvaluation correspondiente, asociada al profesor de la clase, al alumno actual y a la fecha actual. Por defecto se creará en estado pendiente (PENDING). - Añadir un enlace al detalle de una lecture a la lista de lectures que se muestra en el detalle de un curso del estudiante (accesible a través del menú teaching->courses). - Dar la opción de realizar esta valoración también al tutor del alumno (desde el propio detalle de la lecture también). La valoración puede quedar asociada al estudiante correspondiente aunque la realice su tutor.;F;4;4;
377;[Menú] Dividir los elementos del menú en roles más concretos. Ahora mismo todos los profesores tienen los mismos elementos del menú. Habrá que añadir un flag en el JSON, crear JSONs a mayores o algo para aumentar el grado de granularidad del menú y no mostrarle elementos que no deben a los profesores o estudiantes candidatos.;LF;3;4;
376;"[Contenidos] Añadir filtro por idioma en el selector de actividades. Existe actualmente una ventana modal para insertar una actividad en una lesson o en una prueba de nivel. Ahora mismo tiene varios filtros (incluido el de filtrado por nivel). Hay dos formas de afrontar esta issue:  * Añadir un recuadro más de filtros y filtrar por idioma (además de por nivel). * No mostrar ningún selector a mayores, pero filtrar el selector de niveles por ese idioma que se le pasa al componente (si es que se le pasa), mostrando así únicamente los niveles asociados al idioma especificado.  Por si lo anterior no se entendió, pongo un caso concreto: estoy editando una lesson para una clase de chino. Editando la lesson le doy a añadir una actividad y se me muestra la ventana de diálogo con las actividades y los filtros que comentaba. En el filtro de niveles puedo filtrar por un nivel concreto de chino, pero tengo que buscarlo en una lista bastante grande, ya que aparecen los niveles de todos los idiomas. Además, cada vez que abro la ventana de diálogo tengo que seleccionarlo, por lo que es una pérdida de tiempo. Por tanto, la idea es que yo abra esa ventana de insertar una actividad y automáticamente se filtre por el idioma de la lesson, de forma que únicamente me aparezcan actividades de chino y el selector de niveles únicamente me permita seleccionar aquellos que pertenecen al idioma ""CHINO"".";F;2;3;
374;[Gestión] Eliminar los supervisores de un profesor al convertirlo en jefe de estudios. Al convertir a un profesor en jefe de estudios, comprobar si lo supervisaba alguien. Si es así, eliminar esa supervisión (un jefe de estudios no va a tener un supervisor);F;3;3;
373;"[Gestión] Mostrar al alumno sus solicitudes de pruebas de nivel. Un estudiante, desde su entrada ""Levels"", puede solicitar una prueba de nivel.  En esa misma pestaña, encima de los niveles que ya tiene, debería mostrarse un listado con las pruebas de nivel que ha solicitado (mostrando los datos básicos, los mismos que ve el administrador, ordenadas por fecha e incluyendo el estado).";F;4;3;
371;[Gestión-Contenidos] Asociar cuestionarios de prueba de nivel a un estudiante. Un estudiante, desde su vista Niveles/Levels, debería tener la opción de realizar un cuestionario de prueba de nivel para un idioma determinado.  Tendrá un botón para solicitarlo, indicando el idioma. Debería seleccionarse uno de los cuestionarios configurados para ese idioma (Lessons con isLevelTest = true y asociadas con el idioma indicado) y asociarlo con el estudiante correspondiente. Para ello se creará una entidad StudentLevelEvaluation asociada a student y lesson.  Una vez asociado, el estudiante debería tener un enlace para acceder a la lección correspondiente y realizar las actividades. Esto implica realizarlas y que se guarden los resultados correspondientes en una ActivityInteraction asociada a la ActivityLesson correspondiente).;F;3;3;
370;[Gestión] Cobro automático a principios de mes. <s>A principios de mes</s>El último día de cada mes deberían generarse los cobros adecuados en el monedero de cada estudiante para las clases que tenga ese mes.  El comportamiento debería ser muy similar a #361, que hace las comprobaciones de saldo, pero incluyendo la generación de los cobros correspondientes.  El modelo de datos de cobros (WalletPayment) permite generar dos tipos de cobros: asociados a una edición (pensado para los cursos, que se pagan cada mes) y asociados a una clase (pensado para las clases ad hoc). Ahora mismo un cobro solo se asocia a una clase, lo que generaría un cobro por clase en las clases ad hoc en lugar de un cobro mensual (puede modificarse el modelo si se considera necesario).  EDIT: además del proceso de comprobación original, también sería necesario comprobar que no se esté cobrando lo mismo dos veces, dado que en algún caso al configurar un grupo ya se va a cobrar el mes siguiente. Esto podría hacerse simplemente comprobando los cobros en el monedero del usuario, que deberían quedar asociados a la edición (en los pagos de cursos) o a cada clase (en los pagos de clases ad hoc)  En espera por #361;F;2;4;
369;[Gestión] Hacer más evidente que se puede modificar la foto de perfil. Estaría bien que en la página de edición de perfil, al hacer hover sobre la imagen de perfil, apareciera un icono de un lápiz para que fuera evidente que haciendo click se puede cambiar.;US;3;3;
364;[Aula Virtual] Implementación de preview de cámara y micrófono. ;F;3;3;
363;[Chat] Creación automática de salas de chat. ;F;4;3;
361;"[Gestión] Comprobación de saldo de los monederos. En esta tarea se debe implementar un proceso automático de comprobación de saldo de los monederos de todos los estudiantes para asegurar que tienen dinero suficiente para pagar todos sus cursos para el mes siguiente. Ante de esta comprobación, es necesario también revisar los cursos con matrículas activas que sean de tipo clases a medida, y generar las clases para el mes siguiente.  El proceso esperado es el siguiente: - El proceso automático se lanza el día 25 de cada mes. - Se realizan dos procesos principales:   - Revisar las ediciones activas y ""ampliar"" las clases de las que se correspondan con clases ad hoc.   - Comprobar, para cada estudiante que tenga matrículas activas el próximo mes, cual es el importe total que tendría que pagar para cubrir los cursos que tiene actualmente. Notificar al estudiante y al administrador cuando el saldo sea insuficiente.   *Ampliación de clases*  Para cada edición que sea de clases a medida (edition.product.type=ADHOC_XXXX) hay que generar las clases correspondientes al mes siguiente.  - Proceso implementado actualmente: se toma la última semana de clase y se amplía hasta el fin del mes próximo, configurando los mismos días y horas que en la última semana existente. - Proceso ""ideal"": deberían realizarse las mismas comprobaciones de disponibilidad que se realizan al programar la edición inicialmente (#304), para no crear las nuevas lectures en un horario en el que el profesor o algún alumno no tengan disponibilidad.  Ahora mismo el mismo proceso que amplía las clases precalcula el importe que habrá que pagar por cada clase, en función del número de alumnos matriculados, de forma que el siguiente proceso de comprobaciones de saldo simplemente toma el importe guardado en la edición como correcto. Está por ver si esto funciona para los casos atípicos.   *Comprobación de saldo*  Para cada estudiante con matrículas activas, debería calcularse el importe que tendrá que pagar en total, entre todas sus matrículas, el mes siguiente. El cálculo propuesto es el siguiente: - Se considera una matrícula activa la que está activa a día 1 del mes (esto representa dos estados: activa y baja solicitada, siempre que la fecha de baja solicitada sea posterior al día 1). - Para las ediciones de clases a medida, que se pagan por clase (paymetType=PER_CLASS), podemos contar las clases que tiene asignadas el alumno durante el mes. Podemos obtenerlo desde la edición, mirando las lectures programadas para el mes, mirando las attendances y viendo si están asociadas al estudiante (edition.lectures.attendances.student).  - Para las ediciones de cursos (paymentType=PERIODIC), el cálculo es más simple: si tiene la matrícula activa, se cobra el precio mensual.  Se suman los importes de todas las matrículas de cada usuario, y si ese importe es superior al importe actual del monedero, hay que enviar notificaciones. Ahora mismo hay un mecanismo rudimentario para enviar notificaciones implementado en !329, pero al finalizar #363 será necesario integrar las mejoras realizadas allí para el envío de notificaciones.";F;4;4;
360;"[Gestión] Como administrador, quiero ver el estado de todos los monederos. Algunos usuarios del sistema tienen un monedero asociado (clase Wallet), en el que pueden cargar saldo.  En esta issue queremos proporcionar a los usuarios con perfil administrador (""ROLE_ADMIN"") una nueva pantalla en la que podrán ver el estado (saldo actual y fecha de expiración) de los monederos de todos los usuarios, en una vista en forma de tabla.  Revisaremos en persona la estructura del código y las interfaces de la aplicación para poner en contexto algunas explicaciones, pero añado a continuación el detalle del trabajo a realizar.   Trabajo a realizar:   Lado servidor:  - Definir un DTO UserWalletDTO, que será similar a WalletDTO (puede hacer que herede de el o construir otra clase con los mismos atributos) pero también tendrá información básica del usuario (id de usuario y nombre completo; puede crearse un DTO BasicUserDataDTO con estos campos o meter ambos atributos directamente en UserWalletDTO).  - WalletResource.java: modificar el método getAll para que llame a un método de WalletService en lugar de directamente a WalletRepository. Además, deberá utilizar DTOs en lugar de objetos Wallet directamente (devolverá Page<UserWalletDTO>> - WalletService.java: crear el nuevo método ""getAll"", al que se llamará desde el resource, que debe funcionar de la siguiente forma   - Solo estará disponible para usuarios con rol ROLE_ADMIN (usar una anotación ""@PreAuthorize"", hay ejemplos similares en otros métodos de la clase)   - Redirigir la petición a WalletRepository, pero en lugar de recuperar todos los monederos debe recuperar unicamente los monederos de estudiantes que tengan saldo positivo (balance > 0). Esto puede añadirse con un filtro adicional o utilizando Specifications (hay ejemplos de esto en UserDataResource, por ejemplo).   - Convertir cada Wallet a un UserWalletDTO y devolver el paginable (ver como ejemplo WordServiceImpl.findAll)  Lado cliente:  - Crear un listado paginado que acceda a los métodos correspondientes del servidor.   - Puede usarse como ejemplo el actual walletListList.vue, que está accesible en la ruta /wallet-list   - Crear un nuevo componente basado en este en la ruta src/mockups/admin/accounting/, llamado por ejemplo ""WalletList"".   - Modificar el componente para que muestre en cada fila de la tabla los siguientes campos: nombre de usuario, balance del monedero (con tipo moneda para que incluya el símbolo de euro), fecha de expiración   - Eliminar los enlaces de editar y eliminar   - Modificar el método ""entityDetail"" para que redirija a la vista de monedero del usuario (el componente se llama StudentBalanceTab) - Configurar menú superior   - Definir en adminMenuItems.js una nueva entrada de menú para la lista de monederos, que apuntará al nuevo componente ""WalletList"". La nueva entrada de menú puede añadirse dentro de una nueva sección ""Economic management"", que estará al mismo nivel que ""Product management"" o ""User management"".   Notas adicionales: - Es necesario internacionar todos los mensajes (con $t(""xxxx"")). Para atributos del monedero, como el saldo, debería haber mensajes adecuados en src/locale/xx/wallet_xx.js, si hace falta alguno nuevo debería añadirse ahí. - Hay multitud de ejemplos de listados paginados similares a este, pero solo incluyo algunos de ellos. En caso de tener cualquier duda específica sobre el código lo más cómodo es comentarla diractamente en la issue, citandome con @gdebernardo.";F;4;4;
356;"[Aula Virtual] UI nueva para la vista ""cámaras solo"". Si no se está ""enviando"" a los alumnos ninguna actividad, la vista de los alumnos debería mostrar solo las cámaras, y el profesor debería tener alguna opción para que también fuera así (ocultar actividades o algo similar). Parecido a como estaba en los mockups iniciales.";F;1;3;
355;[Aula Virtual] UI nueva para el sistema de mensajería. ;F;1;3;
354;[Aula Virtual] UI nueva para la lista de participantes. ;F;1;3;
351;[Contenidos] Como profesor registrado, quiero ver los resultados de las actividades realizadas por los alumnos asociados a mis clases. ;F;3;4;
349;"[Gestión] Como profesor, quiero asociar un nivel a un alumno. Como profesor, desde la vista de detalle de una clase, quiero poder asociar un nivel a un alumno.  Funcionamiento:  - Esta funcionalidad solo estará disponible si la clase es de tipo ""prueba de nivel"" (levelTest = true) - Hay que mostrar un botón ""Asociar nivel"" debajo del nombre del alumno (ahora mismo la vista LectureDetail de un profesor muestra los alumnos correspondientes, la lógica sería que si es una prueba de nivel se añadirá este botón ""para cada estudiante"", aunque en principio en una prueba de nivel solo habrá un alumno).  - Al pulsar el botón debería mostrarse una ventana modal que tendrá un selector de nivel y un botón de guardar. Al guardar debería crearse en el servidor un ""StudentLevel"", asociada al estudiante correspondiente, la lecture actual, con la fecha actual y el nivel otorgado.";F;3;4;
348;"[Gestión] Un tutor ""borrado"" no debe aparecer en los listados de sus alumnos. Al ""borrar"" (endDate not null) un tutor, debería desaparecer de la lista de tutores de los alumnos que tutorizaba (similar a #282)";F;4;4;
341;"[Gestión] Como profesor registrado/gestor de contenidos, quiero crear ""cuestionarios de prueba de nivel"". Antes de solicitar una clase de prueba de nivel, un alumno podrá realizar una serie de actividades para evaluar su nivel.  Tal y como se ha modelado, la idea es que este conjunto de actividades se agruparán en objetos de tipo ""Lesson"" especiales, que en lugar de estar integrados en una Unit estarán sueltos.  Habrá que añadir una entrada de menú al lado de la de gestionar cursos que permita gestionar estos cuestionarios. Permitirá listar/crear/editar los cuestionarios (que serán ""Lessons"" asociadas a un idioma determinado pero sin unit, y marcadas con isLevelTest=true).  ";F;3;4;
334;[Contenido] Wordlists accesibles públicamente. El endpoint de las wordlists no parece estar protegido y se permite que cualquier usuario pueda acceder a ellas. Se detectó junto con el fallo documentado en la issue https://gitlab.lbd.org.es/lms4.0/webapp/-/issues/333;SE;2;3;
332;[Aula Virtual] UI nueva para el aula virtual: base. ### General - Ajustar colores demasiado tenues para pantallas con bajo contraste.;LF;1;3;
332-2;"[Aula Virtual] UI nueva para el aula virtual: base. ### Menú - Eliminar ""My Campus"" del menú y moverlo a las opciones principales. - Añadir botón ""Share Screen"" en el menú principal. - El botón de ayuda realmente es de soporte, cambiar el texto. ### Vídeos - Los iconos aparecen solamente al mover el ratón por encima. - Añadir el nombre del usuario. - Si hay muchos se estrechan para hacer columnado como máximo de 2. - Mantener arriba y más grande el vídeo de la persona que está hablando. ### Tabs - El ancho de las tabs debe ser variable para que encaje en el ancho total. Se acorta el ancho hasta como mucho el icono. - Añadir botón para ""activar/desactivar"" las ventanas que el profesor comparte a los alumnos. - Marcar de alguna manera las ventanas que se están compartiendo con los alumnos.";LF;1;4;
329;[Chat] Adaptar notificaciones del chat para un usuario empleando varios dispositivos. ;F;4;3;
324;[Contenidos] Mejoras en la visualización/edición de actividades. Para el usuario, las actividades deberían tener los siguientes elementos: - Un skill - Temas de gramática - Temas de vocabulario Ahora mismo se están gestionando como un único conjunto (todo son Topics). Sería preferible tener selectores separados, que permitan asociar específicamente cada uno de los tipos.  La lista de palabras que se pueden incluir en una actividad solo debería permitir seleccionar aquellas que se corresponden al idioma/nivel especificado. Habría que añadir un método que recupere, para un idioma y nivel, las palabras válidas. Estas serán las palabras de la wordlist asociada al idioma/nivel de la actividad, así como las palabras de todas las wordlists descendientes de ella (cada Wordlist tiene un atributo childWordlist con su descendiente directa).;F;1;3;
323;"[Gestión] Como administrador, quiero ver las evaluaciones realizadas por alumnos/tutores.   Como administrador, debería tener una entrada de menú para acceder a un listado de evaluaciones de profesores (puede añadirse como una entrada de menú nueva o dentro de ""product management"")  En este listado, se mostrarán todas las evaluaciones de profesores en estado pendiente (PENDING), en una tabla paginada estándar, mostrando primero las más recientes. Para cada evaluación debería mostrarse el nombre del profesor, el nombre del alumno, la fecha y los comentarios.  El administrador tendrá dos acciones posibles para cada evaluación: aceptarla (hacerla pública) o rechazarla (pueden verse ejemplos de iconos para este tipo de acciones en el listado de productos que hay en ""Product management"", o en la pestaña ""education"" de un profesor).  Al pulsar en cualquiera de los botones de acción, se debería mostrar una ventana modal de confirmación (similar a la que se muestra en otros listados, en los botones de borrado), y si se acepta se cambiará el estado de la StudentEvaluation a PUBLIC o REJECTED respectivamente. Dado que dejarán de aparecer en el listado al estar rechazadas, habría que eliminarlas de la vista de la misma forma que se hace en los borrados.";F;1;4;
322;[Gestión] Como profesor, quiero ver las evaluaciones públicas que he recibido por parte de los alumnos. (Esta incidencia es muy similar a #305, destaco las diferencias más relevantes):  Similar a 305: - Desde el perfil de un profesor, este tendrá acceso a las evaluaciones (TeacherEvaluation) que ha recibido por parte de alumnos, que se mostrarán en un listado ordenadas, y buscable por edición y alumno.  Diferencias, y cambios en el modelo de datos: - El profesor solo verá las evaluaciones públicas (habrá que crear un endpoint específico para recuperar las evaluaciones públicas). Esto implica añadir a `TeacherEvaluation` un atributo `state`, que se corresponderá con un enumerado `TeacherEvaluationState` con los valores posibles PENDING, PUBLIC, REJECTED. Por lo tanto, el profesor solo verá las evaluaciones en estado PUBLIC.;F;3;4;
315;[General] Configuración de menús.  La página de inicio de la aplicación, en lugar de ser la actual en blanco, será la página de login. Por lo tanto debe desaparecer también el icono de acceso a la página de login para usuarios no autenticados.  Vamos a configurar correctamente menús en la aplicación para que permitan acceder a la información que ahora mismo solo se ve entrando a través del perfil en la barra lateral. La idea es mantener de momento también la barra lateral, aunque posiblemente también desaparezca en un futuro, y replicar los accesos a los elementos principales desde un menú clásico.   Menú público (usuarios no registrados): - Idioma (desaparece el listado de productos para usuarios no registrados)  Administrador   - Profesorado    - Candidatos    - Registrados - Alumnado   - Candidatos   - Registrados   - Tutores - Docencia   - Productos   - Pruebas de nivel   - Matrículas - Usuarios    - Editores de contenido    - Administradores    - Todos (cuentas de usuario de momento) - Idioma  - Perfil      *Profesor:* - Docencia   - Disponibilidad   - Calendario (por el momento pueden apuntar ambas al calendario actual)   - Cursos   - Clases - Gestión   - Pagos  - Idioma  - Perfil    - Información personal    - Educación    - Referencias    - Datos bancarios    - Legal   *Alumno:* - Docencia    - Niveles    - Disponibilidad    - Calendario (esta y la anterior apuntarán al calendario)   - Cursos  - Monedero    - Saldo    - Movimientos  - Idioma  - Perfil    - Información básica    - Valoraciones    - Records   *Tutor:* - Alumnos supervisados - Monedero    - Saldo    - Movimientos  - Idioma - Perfil;LF;1;4;
312;[Chat] Implementación de persistencia en mensajería. Implementación de persistencia según el modelo de datos:   ;O;4;3;
311;"[Contenidos] Como gestor de contenidos, quiero eliminar una actividad del servidor H5P. Borrado de ""caja blanca"".";F;1;4;
309;[Pagos] Mejoras en los pagos. * Añadir un timeout y un botón para redirigir al usuario de nuevo a la vista del monedero tras realizar un pago con Redsys. * Permitir realizar recargas del monedero de cantidades que no sean necesariamente enteros (p.ej.: 23,35€).;F;3;4;
305;"[Gestión] Como alumno, quiero ver las valoraciones que he recibido por parte de mis profesores.. En el perfil de un alumno existe una pestaña ""Feedback"" que actualmente no tiene contenido. En esta pestaña debería mostrarse al alumno la información de las valoraciones que ha recibido por parte de sus profesores.  - Debería mostrarse un listado con todas las entradas de StudentEvaluation asociadas al estudiante actual. Estas pueden calcularse mirando la Attendance a la que pertenecen, y extrayendo de ahí el estudiante. En el servidor debería implementarse un método que permita recuperarlas por id de estudiante, con la opción de filtrar también por curso/edition y por profesor (ver más adelante) - Se mostrará el listado en una tabla paginada, al estilo del resto de listados de la aplicación. No habrá acciones asociadas, solo podrán verse los datos. Para cada entrada, se mostrará la fecha, los comentarios, el curso (attendance.lecture.edition.product.name) y el profesor que la ha realizado (su nombre a mostrar) - Deberían añadirse los siguientes filtros de búsqueda: por curso (mostrando un selector con el nombre de la ""Edition"") y por profesor (mostrando un selector por nombre de profesor). - Los resultados aparecerán por defecto ordenados por fecha, comenzando por los más recientes. - Si el estudiante es menor de edad, no verá esta pestaña. Si la verá su tutor, que podrá acceder a esta información. Por este motivo, en el lado servidor será necesario comprobar que la consulta realizada sea por parte de un estudiante mayor de edad, sobre sus datos, o por parte de un tutor sobre un estudiante que supervisa.";F;4;4;
304;[Gestión] Como administrador, quiero programar clases a medida.  En la lista de solicitudes de productos, el administrador puede configurar grupos de clases a medida.  Si las clases son one-to-one: - El proceso de asociación será similar al de una prueba de nivel: se buscará un profesor (con la diferencia de que se comprobará que tenga horarios compatibles durante 4 semanas, y no solo una hora) y se asociará. - Cuando se confirme el profesor, se crearán la Edition, la Registration del alumno y las Lectures correspondientes al primer mes, con las Attendances del alumno.  Si las clases son one-to-two o adhoc-group: - El proceso será similar al de un curso: se buscará un grupo de alumnos que hayan solicitado el mismo producto en las mismas condiciones (p.ej., mismo número de clases semanales), y un profesor, que tendrán que tener horarios compatibles durante 4 semanas. - Se creará la edición, las Registrations y las Lectures igual que en el caso anterior, pero añadiendo matrículas y attendances a todos los alumnos.;F;2;4;
301;"[Gestión] Comprobaciones para solicitar una prueba de nivel.  Un alumno adulto (o el tutor de un alumno infantil) puede solicitar una prueba de nivel para un idioma desde la pestaña ""Levels"". Hay que añadir algunas comprobaciones en esta pestaña: - La prueba de nivel puede solicitarse sin indicar una fecha límite (quitar el control de campo obligatorio) - Si el alumno no tiene disponibilidades indicadas, debería mostrarse un aviso en la página diciendo que para solicitar una prueba de nivel es necesario haber cubierto los periodos de disponibilidad en el calendario.";F;3;4;
295;[Gestión] Como profesor, quiero ver los detalles básicos de una clase que imparto. Necesitamos crear una vista básica de detalle de una Lecture a la que podrá acceder el profesor que la imparte.  La vista mostrará:  - Los datos básicos de la clase: estado (planificada, realizada, cancelada) y en su caso la fecha y hora planificadas. - El listado de alumnos. El listado básico puede incluir los nombres y las fotos, pero pulsando en cada alumno debería poder verse la foto del alumno, su nombre y apellidos, país, género, edad, nombre completo de los tutores y relación con el alumno. - La lista de actividades asociadas a la clase.;F;2;4;
292;"[Gestión] Como alumno, quiero ver los datos básicos de cada curso en el que estoy registrado. Desde la lista de cursos en los que está registrado un alumno (RegistrationsTab), deberíamos tener un acceso a la información básica del ""curso"" correspondiente. Esta vista debería incluir:  - La información básica del producto (título, descripción, etc.) y el estado de matrícula, de la misma forma que se muestra en  la lista de matrículas. - La información básica del profesor que imparte la ""Edition"" correspondiente. Esta información incluirá el nombre a mostrar, foto, género, about me. - La información básica de otros alumnos. No está claro cuanta será, pero puede incluirse el nombre a mostrar. - La lista de ""Lectures"" asociadas a esta edición (ordenadas por fecha), con una opción de filtro para mostrar/ocultar las lectures pasadas. Esta lista será muy similar a la que puede verse en Lists>Lectures, mostrando todas las Lectures en las que exista una Attendance asociada al alumno actual, y permitiendo filtrar las pasadas. Sin embargo, estas vistas usan elementos específicos del aula virtual, aquí deberían consultarse métodos nuevos a nivel de Resource y Service. Quedaría pendiente en el futuro la refactorización de las funcionalidades de aula virtual en otros puntos de la aplicación.";F;3;4;
286;[Chat] Implementación cliente de mensajería y servicio REST. Cliente web, REST respondiendo a las peticiones y guardando las cosas en memoria (o sin guardarlas).;F;4;3;
284;[General] Añadir librería de loggin para vuejs. Librería: https://github.com/justinkames/vuejs-logger  Para cambiar todos los logs que tenemos en el aula virtual, así podemos dejarlos permanentemente y gestionar si se ven o no dependiendo del build.;O;4;3;
283;"[Gestión] Envío de email de referencias.. El email que se envía ahora mismo para solicitar referencias no incluye ninguna plantilla para solicitar estas referencias.  Cambios: - Añadir un método genérico de utilidad en MailService que sea capaz de enviar un email con archivos adjuntos (uno o más). Esto implica en principio asegurarse de que el email es multipart, que el texto se mete como HTML y que los diferentes archivos se añaden como attachments.  - Modificar MailService.sendRequestTeacherReference para que añada un documento de referencias como adjunto al email actual. El documento base es [este]. Hay que copiar el archivo a ""resources"" y cargarlo para su envío como adjunto.  Es importante probar el envío de este email con adjuntos, en particular que el email enviado se ve correctamente en diferentes clientes de correo (Outlook, Gmail).";F;3;4;
282;"[Gestión] Un jefe de estudios no debe ver profesores que supervisa si están borrados. Los profesores borrados (son los que tienen un valor en endDate) dejan de aparecer en los listados de profesores. Tampoco deberían aparecer en los listados de profesores que supervisa un jefe de estudios, ni en la ventana modal de selección de nuevos profesores para supervisar.  Cambios: - Cuando un profesor se borra, no debe aparecerle como supervisado al jefe de estudios. - Cuando queremos añadir un profesor supervisado a un jefe de estudios, la lista de ""notSupervised"" debe mostrar solo profesores no borrados. - Revisar los mensajes correspondientes a añadir/borrar profesores supervisados por un jefe de estudios.";F;3;4;
280;[Gestión] Al editar un estudiante registrado se convierte en candidato. El problema parece asociado al código en StudentServiceImpl.updateStudent, donde se fuerza la authority student_candidate sin hacer otras comprobaciones. Desde el perfil de usuario, al editar (o al editarlo como admin) deberían conservarse las authorities que ya tenía. Solo en el caso de que fuese guest se pasaría a candidate (y entiendo que esto es solo en la creación, no en el update).   Trabajo:  - Cambiar el código para que no resetee las authorities.  - Revisar que no haya efectos secundarios: un estudiante guest, cuando cubre sus datos, pasará a candidate.;SE;3;4;
278;"[Gestión] Un usuario no puede asociarse como su propio tutor. Cuando me registro y cubro los datos como alumno menor de edad, se envía un correo de confirmación al tutor que indique. El tutor puede ir al enlace ""Vincular"", que en principio vincula un usuario existente como tutor del alumno que corresponda. Ahora mismo, si lo hago en el mismo navegador, me permite hacerlo y asocia al alumno como su propio tutor.  Cambios: - Añadir una comprobación de que un usuario no puede ser tutor de sí mismo (dar un error si se intenta) - Añadir una comprobación de que un usuario menor de edad no puede asociarse como tutor (dar un error si se intenta)";F;4;3;
277;[Gestión] Eliminar solicitudes de prueba de nivel caducadas. Añadir en el servidor, en LevelTestRequestService, un método @Scheduled que se ejecutará diariamente para eliminar las pruebas de nivel caducadas. Básicamente el método debe buscar las levelTestRequest en estado REQUESTED cuya fecha límite ya haya pasado, y cambiar su estado a REJECTED. (en #254 se ha creado un método @Scheduled similar que puede verse en FileServiceImpl);F;4;4;
276;"[Gestión] Mejoras en visualización del monedero. En el monedero de un estudiante/profesor/tutor hay que hacer los siguientes cambios:  - En la vista de ""Balance"", asegurarse de que el importe se visualiza como moneda para que se vea el símbolo de € (hacerlo como en la vista de movimientos) - En la modal que aparece cuando pulsamos en añadir fondos, mostrar también el símbolo de euro en la cantidad/amount. - En el listado de movimientos, mostrar un mensaje de que no hay datos (similar al que se muestra en la lista de documentos o de niveles) cuando no haya ningún movimiento.";F;4;4;
275;[Gestión] Validación en cliente de login y contraseña: formularios de registro. Ees necesario comprobar los campos de login y contraseña en todos los formularios de registro: - Registro como usuario en la página principal - Registro como tutor - Registro de profesores/estudiantes/otros como administrador  La idea es revisarlos y añadir las mismas validaciones en cliente que hemos incluido en el login: regex del login y control de la longitud de la contraseña.;F;4;4;
271;"[Gestión] Como administrador, quiero ver las solicitudes de matrícula. Añadir un listado a las opciones del administrador para ver la lista de solicitudes de matrícula. El comportamiento y la visualización será algo muy similar a lo hecho en #207 para las solicitudes de pruebas de nivel.  - La vista por defecto mostrará la lista de ProductRequest que estén en estado ""REQUESTED"" - En la lista se mostrarán los datos básicos de la solicitud (Nombre completo del alumno, fecha de solicitud, fecha límite, nombre del producto concreto, clases semanales) - También habrá botones para aceptar (de momento no hará nada, se abordará en otra issue) y rechazar. Estos cambiarán el estado de la solicitud a aceptada o rechazada (será necesario añadir en el modelo el valor REJECTED al enumerado RequestState, ya que ahora mismo no existe)";F;3;4;
270;[Aula virtual] Duplicación de dependencia stomp client. Múltiples dependencias a stomp client en package.json cuando solo se está empleando una.;F;3;3;
269;[Gestión] Validación en cliente: formulario de login. Realizar en cliente, en el formulario de login, las mismas validaciones que se realizan ahora mismo en el servidor, para evitar que se pueda enviar una petición de login que cree un error interno. Las validaciones básicas son las que hay en UMUser:  - El login tiene una longitud máxima de 50 (podemos establecer maxlength en el campo) - El login solo puede tener determinados caracteres (añadir el patrón a regex-validation.js, para que podamos reutilizarla en otros formularios, y comprobarla igual que se hace ahora con el email) - La contraseña también tiene una longitud mínima y máxima.;SE;4;3;
264;[Gestión] NIFs y fechas de expiración. Ahora mismo en la mayor parte de los formularios el NIF no es obligatorio pero su fecha de expiración sí. Además, el campo de fecha de expiración no permite seleccionar fechas futuras en todos los casos.   Cambios: - Quitar la obligatoriedad de la fecha de expiración en todos los formularios (se incorporará en el futuro de nuevo solo en los casos en los que el NIF también sea obligatorio). - Revisar la configuración de la fecha de expiración en todos los formularios. En mis pruebas al menos en el formulario de editar un administrador el campo permite seleccionar fechas pasadas en lugar de futuras.;F;3;4;
263;"[Gestión] Eliminar funcionalidades obsoletas de gestión de usuarios. Actualmente sigue activa la vista ""User management"", que procede de la LPS original y no está actualizada para gestionar los nuevos perfiles de usuario. Para evitar problemas durante las pruebas, vamos a eliminar de la vista las acciones que ya no son aplicables o que no están actualizadas:  Cambios: - Quitar el botón ""New"" que añadía un nuevo usuario - Quitar de cada fila los botones de edición y de borrado. Dejaremos como únicas funcionalidades el slider para activar/desactivar cuenta y el botón de resetear contraseña.";US;4;3;False
256;"[Gestión] Como estudiante, quiero solicitar la matrícula en un curso. Como estudiante adulto, quiero poder solicitar la matrícula en un curso (Product) determinado. Esta opción debería estar disponible desde el listado de productos, o desde la vista de detalle de un producto. El comportamiento será muy similar a la solicitud de clases de prueba (LevelTestRequest), pero en este caso se crearán solicitudes de matrícula en ""productos"" (ProductRequest).  - Debe mostrarse una modal donde el alumno puede indicar la fecha ""límite"" (hasta cuando está dispuesto a esperar) y el número de clases semanales (esta opción solo podrá modificarse si el producto es de tipo ADHOC y no se ha especificado un valor en el producto). No será obligatorio cubrir ninguno de los campos. - Al guardar debe crearse una ProductRequest en estado REQUESTED. La fecha de solicitud será la actual, y se especificará también la fecha límite y clases por semana si el usuario los marca";F;3;4;
255;"[Gestión] Dar matrículas de baja. Crear un proceso automático diario para dar de baja matrículas en la fecha en que se solicite El proceso debería lanzarse diariamente y buscar matrículas en estado WITHDRAW_REQUESTED cuya fecha de baja (withdrawConfDate) ya haya pasado. Para cada una de ellas, debe marcarse la matrícula correspondiente como INACTIVE.  Como parte de la tarea, y para poder validarla, añadir a data.sql matrículas en los diferentes estados, en particular al menos una en estado WITHDRAW_REQUESTED ""caducada"" y otra ""sin caducar"".";F;3;4;
253;"[Gestión] Modificaciones en wordlists. Necesitamos hacer algunos cambios en los funcionamientos de una wordlist:  - Habrá una jerarquía de wordlists: cada wordlist tendrá una wordlist ""superior""/""inferior"" (de forma que por ejemplo la wordlist de inglés de nivel A1 tendrá como superior la de A2, la de A2 como superior la de B1, etc).  - Cada palabra podrá tener asociados un conjunto de temas. Para ello, tendremos que tener una entidad nueva ""WordTopic"" o similar, que permita asociar una Word y un Topic, y asociar a cada palabra una lista de WordTopics (de forma muy similar a como se hace ahora con las actividades).  A partir de aquí habrá que cambiar el funcionamiento de las vistas actuales de la siguiente forma (puede delegarse a otra issue): - En la ficha de una wordlist, mostrar:   - El nombre de la wordlist ""superior"" e ""inferior"", como enlaces.   - Para cada palabra, etiquetas con los nombres de los temas asociados - En el formulario de una wordlist, permitir asociar la wordlist superior/inferior y asociar a cada palabra varios temas.";F;2;2;
250;[Gestión] Como estudiante, quiero darme de baja de un curso. Un estudiante adulto (o su tutor si es menor) puede solicitar la baja en un curso en el que está registrado .  Propuesta: - Añadir un botón de darse de baja en cada entrada de la lista. Solo estará visible si el alumno está de alta - Al pulsar el botón se mostrará una modal en la que el alumno podrá indicar en qué momento quiere hacer efectiva la baja (por defecto, poner la fecha actual, pero que pueda cambiarla). - En el servidor, se guardará la fecha de hoy en withdrawReqDate y la fecha de baja solicitada en withdrawConfDate. Se actualizará el registro al estado WITHDRAW_REQUESTED.;F;3;4;
246;[Gestión] Un alumno mayor de edad no debería tener acceso a la opción de tutores. Ahora mismo los alumnos mayores de edad tienen en su barra lateral la opción de ver sus tutores, y tienen incluso la opción de añadirlos. Esta entrada de la barra solo debería estar visible si el alumno es menor de edad.;SE;3;3;
244;"[Gestion] Mejoras en las vistas de gestión de productos. Los productos sólo son editables y eliminables cuando se encuentran como borradores o como desactivados. Así pues, el listado no permite editar/borrar los nuevos productos que se crean (los de prueba, por algún motivo, sí funcionan bien).  Dentro de la vista de detalle de un producto se están mostrando siempre los botones, incluso cuando el producto está público, por lo que habría que cambiar el comportamiento para que sea igual que en el listado: sólo se permite editar y borrar cuando el producto está en estado ""DRAFT"" o bien está oculto a los usuarios.";F;3;3;
240;"[Gestión] Cambios en disponibilidades en el calendario. Gestionar las disponibilidades con timeslots genera problemas con los timezones, por lo que vamos a cambiar la forma de gestionar las disponibilidades:  - Las entidades ""StudentAvailability"" y ""TeacherAvailability"" dejarán de tener referencia a un TimeSlot, y en su lugar tendrán una startDate y endDate (de la misma forma que lo tienen ahora las unavailabilities). - En la vista de calendario se cargarán las disponibilidades correspondientes a la semana actual (de la misma forma que antes se hacía con las no disponibilidades). - La pantalla de edición de disponibilidades pasará a funcionar de la siguiente forma:   - Visualmente puede mantenerse igual que hasta ahora, permitiendo escoger fragmentos de media hora (salvo que resulte más cómodo permitir crearlos directamente pulsando en el calendario, al estilo de google calendar o similar).   - Internamente, esos fragmentos se convertirán a ""Availabilities"", asociadas al día concreto en lugar de a un día genérico de la semana. Esto quiere decir que editar las disponibilidades se aplica a la semana actual.   - Habría que añadir un check o similar, que diga ""Aplicar estas disponibilidades de ahora en adelante"", de forma que al marcarlo se pueda escoger una fecha límite (por defecto podemos poner 3 meses). Si se selecciona, las disponibilidades indicadas para la semana actual se copiarán también a los días equivalentes de próximas semanas hasta la fecha límite indicada.   - Ojo: todas las disponibilidades indicadas se debe entender que están generadas en la timezone del usuario actual. Antes de enviarlas al servidor deben transformarse a UTC. Al recuperar la información del servidor se entenderá que está en UTC y debe transformarse también al timezone del usuario";F;2;4;
236;"[Aula Virtual] Echar a participante de una reunión. Las funcionalidades de gestionar la reunión del Zoom no nos llegan (ni aunque funcionaran bien), algo que era más o menos previsible. Vamos a mirar de meter websockets o algo similar para gestionar toda la parte de controlar la reunión, relegando a zoom a simplemente las funciones de vídeo/screesharing.   En esta issue empezaremos con este tema con la historia de usuario ""Como profesor quiero poder a echar a un alumno de una clase virtual"".";F;4;4;
234;[Gestión] Lista pública de productos disponibles. Un estudiante debería poder listar y buscar de entre los productos disponibles. De hecho, esta funcionalidad probablemente termine siendo pública, por lo que la vista y búsqueda de datos básicos de los productos no debería controlarse por perfil.  - En el lado cliente propongo crear una vista muy simple, pero diferente de la que se usa ahora mismo para el administrador. El motivo es que esta vista, al ser pública, probablemente se mejore visualmente en el futuro, y termine siendo bastante diferente de la de gestión. - Los productos que podrán consultarse serán aquellos que estén en estado público. - Las funcionalidades de búsqueda deberían permitir buscar al menos por idioma y por tipo de producto - Desde esta pantalla habrá una funcionalidad para ver el detalle del producto (a abordar en otra issue);F;4;3;
232;"[Gestión] Como profesor, quiero ver/editar la lista de niveles en los que puedo dar clase. (propuesta: añadir esta funcionalidad en la vista ""Education"" del profesor)   - Como profesor candidato/registrado, debería poder ver la lista de niveles en los que puedo dar clase. De cada nivel veré el idioma/nivel, y el estado. El administrador verá esta misma vista   - Modelo: eliminar la entidad TeacherLevelStatus y reemplazarla por un enumerado, que contenga los valores PENDING y ACCEPTED.  - Tendré un botón para añadir un nuevo nivel, en el que simplemente podré seleccionar el nivel y guardar. El nuevo nivel se añadirá siempre en estado PENDING (Esto puede delegarse a otra issue) - El administrador tendrá un botón para ""confirmar"" un nivel, cambiando su estado a ACCEPTED (esto también puede delegarse a otra issue)";F;3;4;
231;"[Data-model] Contenidos para evaluación previa de nivel. Antes de realizar la clase de evaluación de la prueba de nivel, para un nivel determinado, un estudiante puede libremente realizar una serie de actividades destinadas a evaluar su nivel de forma preliminar. Para permitir configurar conjuntos de actividades viables como pruebas de nivel necesitamos algo similar a una Lesson que pueda funcionar en solitario, sin estar integrada en un curso.  Para evitar introducir muchos elementos nuevos en el modelo, mi propuesta es extender las ""lesson"" actuales con nuevos atributos para poder despues crear las pruebas de nivel como Lessons, reutilizando buena parte de las funcionalidades ya existentes.  Mi propuesta sería: - Añadir a la Lesson los siguientes atributos   - isLevelTest: boolean (o similar) para indicar que esta lección puede usarse como prueba de nivel   - language: Language para indicar a que lenguaje se corresponde - Añadir una entidad `StudentLevelEvaluation` para relacionar un Student con las Lesson que se le han asignado como evaluaciones previas de nivel:   - id   - student:Student   - Lesson: lesson - Añadir un atributo ""activityLesson: ActivityLesson"" a ""ActivityInteraction"", para poder registrar la interacción de un usuario con las actividades de esas ""lessons"" aunque no exista una clase programada para ellas. (manteniendo el atributo ""ActivityLecture"" que había antes también; la idea sería que siempre estará uno de los dos cubierto y el otro en blanco). - Revisar que los cambios en el modelo no provocan ningún conflicto en la actual edición de cursos/lecciones/...";F;1;3;
228;"[Contenidos] Como gestor de contenidos/profesor registrado, quiero ver el detalle de una actividad.. Tendremos un acceso a ver detalle desde la lista de actividades. En esta vista de detalle de una actividad debería mostrarse: - Datos básicos de la actividad: título, descripción, idioma/nivel, tipo de actividad (activityType) - (Pendiente, por definir) un mecanismo para ""previsualizar la actividad"") - Lista de temas (activityTopics) - Lista de palabras que utiliza (activityWords)";F;3;4;
225;"[Aula Virtual] Listado de Lecture con posibilidad de unirse al aula virtual. Vamos a asociar el aula virtual a clases concretas, con su lista de participantes, fecha de inicio, de fin, etc. Para ello:  * Metemos en el script `data.sql` datos de prueba. Concretamente meteremos una clase que empiece 5 minutos después de que se lance la aplicación, y podemos crear otras dos más (con menos detalle) para que se muestren en el listado, una de ellas que sea 3 horas después y otra 27 horas después o algo así.   * Esto se puede hacer usando NOW() y alguna función en el script, si tienes problema me preguntas y te paso un ejemplo. * Creamos un componente super básico que sirva para listar las ""Lecture"" del usuario logueado, de forma que aparezca primero las más recientes. Para cada lecture ponemos el nombre de la Lesson asociada, la fecha/hora de la Lecture,  el nombre del profesor, el número de alumnos.   * Componente vuejs accesible desde el menú Lists, con un nuevo controlador y un DTO con los datos que se necesiten (Lecture tiene un porrón de cosas que no nos hacen falta, haremos DTOs concretos en función de la vista que necesitemos).    * Estaría bien que aparecieran solo las Lecture de hoy en adelante. Es decir, si entrara en la interfaz a las 13:00, podría aparecer de primera la Lecture que tuve a las 10:00, con un color para indicar que ya ha pasado, luego otra lecture que tengo a las 15:30, y luego otra que t3engo mañana o pasado, por ejemplo. Para ver las Lectures pasadas (sin contar las de hoy) tendríamos un checkbox que sea ""Mostrar las lectures pasadas"", y que entonces se refrescan los datos y solo aparecen las Lectures pasadas (incluida la de hoy), también de más reciente a más vieja. * Cada Lecture tiene un botón para unirse que está habilitado cuando falten 10 minutos para empezar la Lecture.   * Aquí hay que investigar si los alumnos pueden entrar a la reunión antes que el proffesor, porque yo creo que no para evitar que se hagan ""owners"" de la reunión de Zoom. Hay que investigar el tema. Si es como pienso, los alumnos solo verían habilitado el botón cuando el profesor se una.";F;4;2;
224;[Aula Virtual] Usar los datos del usuario logueado para la reunión. ;F;4;3;
223;"[Gestión] Ajustes en formulario de estudiante invitado. En el formulario con sus datos que cubre el estudiante invitado tras registrarse, si es menor de edad, tiene que indicar un tutor (componente TutorForm). El campo ""relación"" debería marcarse y validarse como obligatorio en cliente (ya que lo es en el servidor).";F;2;4;
222;"[Gestión] Ajustes en formulario de registro. - Marcar el idioma como obligatorio - Revisar i18n: el rol ""Student"" aparece en inglés para el idioma español.";F;3;4;
221;[Gestión] Registro como tutor: campos obligatorios. En el registro como tutor de un estudiante menor (url/account/tutor/create, componente TutorRegister) es necesario completar los campos obligatorios. Esto incluye marcarlos como obligatorios, asegurar que se validan y que el botón de guardar solo se active cuando estén todos cubiertos.  Los campos obligatorios serán: - Nombre, apellidos, nombre mostrado, ~~fecha nacimiento~~ - Login, email principal, contraseña, rep. contraseña;F;3;4;
218;"[Gestión] Logos. Es necesario añadir logos relativos a financiación del proyecto en el footer de todas las páginas   Un ejemplo de formato para mostrarlos será el siguiente: ![formato](/uploads/97181e469a773365f4001828edaf9ecf/formato.png)  (El texto que aparece en el medio (""Fondo europeo...."") puede colocarse debajo de los logos, en una línea, si resulta más adecuado para visualizar. El tamaño relativo de las imágenes es importante, el footer debería ajustarse lo máximo posible al modelo ).  Enlaces a los logos: - [igape](http://www.igape.es/images/logotipos/png/grande/logo-igape.png) - [xunta](http://www.igape.es/images/logotipos/png/grande/logo-xunta.png) - [UE](http://www.igape.es/images/logotipos/png/grande/logo-UE.png) - [xacobeo](https://igfae.usc.es/igfae/wp-content/uploads/2020/02/xacobeo-color-1.png) - [galicia](http://www.igape.es/images/logotipos/png/grande/logo-galicia.png)  Trabajo: - Añadir las imágenes (en /public/img/logos, por ejemplo) - Crear un componente Footer que muestre la información de todos los logos. Puede añadirse dentro de una carpeta nueva src/components/footer. Utilizar el [v-footer](https://vuetifyjs.com/en/components/footer/) para construirlo. - Añadir en App.vue el nuevo componente, para que esté disponible en todas las páginas. Asegurarse de que en la página inicial y en la página de login se ve correctamente sin necesidad de hacer scroll.";US;4;4;
213;"[Gestión] Refactorizar código replicado. En el servidor, habría que refactorizar las comprobaciones que se hacen para recuperar datos relativos a un estudiante a una función común (siempre se comprueba que se administrador, el propio estudiante mayor de edad o el tutor de este). En caso de haber variaciones en estas comprobaciones, se pueden hacer distintas funciones para cada una de ellas.  Por el otro lado, en el cliente, se repite en varios componentes el método para pasar el array con la fecha del servidor al objeto Date de Javascript; habría que refactorizar este código a una función común a reusar en todos estos componentes.";F;2;3;
212;"[Gestión] Mejoras en listado de referencias. Habría que realizar las siguientes mejoras en la parte de referencias:  - Servidor:   - Crear un servicio específico para las referencias.   - Mover la descarga del fichero de TeacherResource a ReferenceResource.   - Solucionar el get de todas las referencias de un profesor. - Cliente:   - Cambiar la notificación de descarga, por ""Descargando fichero."" a ""Fichero descargado"".";F;3;3;
207;[Gestión] Como administrador, quiero ver la lista de pruebas de nivel solicitadas.. Añadir un nuevo listado al administrador, en el que podrá ver la lista de solicitudes de pruebas de nivel. Solo se mostrarán las pruebas de nivel solicitadas (state=REQUESTED). Deberían mostrarse ordenadas por fecha (de más antigua a más reciente).  En el listado debería mostrarse el nombre del estudiante, la fecha de creación y límite y el idioma. Tendrá dos botones:  - Aceptar (aquí engancharemos la funcionalidad de asociar un profesor, en otra issue)  - Rechazar (se cambiará el estado a REJECTED - hay que añadir este estado al enumerado);F;3;4;
206;[Gestión] Como estudiante, quiero solicitar una prueba de nivel en un idioma.. Desde la vista de niveles, un estudiante tendrá una opción de solicitar una prueba de nivel. El botón abrirá un formulario en el que podrá indicar:  - Idioma (en principio será un idioma en el que no tenga ya un nivel asignado). - Fecha límite (fecha hasta la que está dispuesto a esperar para realizar la clase).  Internamente se creará un objeto LevelTestRequest, con los siguientes valores: - student asociado al estudiante - date con la fecha actual - lecture a null - state a REQUESTED  Un tutor podrá realizar esta solicitud desde la vista de un estudiante menor de edad al que supervise. Un administrador no tendrá el botón disponible.;F;3;4;
205;"[Gestión] Eliminar controles de email duplicado. - Eliminar la excepción AccountEmailInUse - Eliminar UserRepository.findOneByEmail. - Eliminar las llamadas a este método en AccountResource (update y validate); ahora se permitirán varios usuarios con el mismo email. - Modificar el método de recuperación de contraseña. El usuario tendrá que indicar su login en lugar de su email. Creo que UMMAilJSON solo se usa en este caso, por lo que se reemplazaría por un nuevo objeto que contenga el login). En el servidor el control será muy similar al actual, simplemente se recuperará por login y se enviará al correo asociado a ese login.";F;3;3;False
204;"[Gestión] Crear periodos de no disponibilidad ""sin horario"". No resulta muy cómodo obligar a introducir la hora de inicio y fin de no disponibilidad en todos los casos. Si un usuario quiere indicar que no estará disponible un día entero, sería útil que se ahorre indicar las horas.  Mi propuesta es simplemente que la hora de inicio sea 00:00 al cargar el formulario, y la hora de fin del periodo 23:59 en este caso.  Como mejora, podría añadirse un checkbox que indique ""todo el día"", y que los valores de las horas se cubran solo si este checkbox está activado.";A;4;3;
201;[Gestión] Fechas de expiración. Se está utilizando el birthdayPicker para las fechas de expiración de NIF, lo que impide introducir fechas futuras. Propongo renombrarlo y añadir una prop que permita indicar el tipo de fecha a incluir (la usada para los cumpleaños, que permitirá fechas pasadas, y una opción para fechas futuras, para las fechas de expiración, que tomará como rangos de años los 40 próximos, por ejemplo).;US;3;3;
199;"[Gestión] Como estudiante, quiero subir nuevos ficheros a la plataforma. Desde el listado de ficheros propios, un estudiante puede subir nuevos ficheros. El formulario debería permitir: - Seleccionar el tipo (obligatorio) - (si se selecciona tipo ""Otro""/OTHER) Indicar una descripción (obligatorio) - Asociar el fichero (obligatorio)  Un tutor tendrá acceso también a esta funcionalidad para un alumno que supervise. Como entiendo que no supone esfuerzo adicional, podemos permitir también al administrador que lo haga, para cualquier estudiante.";F;3;4;
198;[Gestión] Ficheros subidos por un estudiante. Los estudiantes tendrán una funcionalidad para subir ficheros a la plataforma.  - Un estudiante (candidato o registrado) mayor de edad podrá gestionar su propia lista - Un administrador podrá ver el listado de cualquier estudiante - Un tutor de un estudiante menor de edad podrá gestionar la lista del estudiante.  Dado que no está claro en este punto que otros perfiles podrán subir ficheros, en el modelo se incorpora la clase UserFile que puede asociarse a cualquier usuario.   Trabajo en esta tarea: - Crear un componente genérico que permita listar los ficheros correspondientes a un UserData por id. De cada fichero solo se mostrará el tipo, la descripción (que normalmente solo estará cubierta si el tipo es OTHER) y un enlace para descargar el fichero. - Añadir en la pestaña DocumentsTab del estudiante la lógica para mostrar la lista de ficheros asociados a el.;F;3;2;
193;[Gestión] Lista de cursos en los que está matriculado un estudiante. Mostrar la lista de matrículas (Registrations) del estudiante correspondiente. Los datos deberían mostrarse ordenados por fecha (añadir un atributo registrationDate, de tipo LocalDateTime, a la entidad Registration), comenzando por las más recientes. Debería mostrarse para cada entrada el estado (Alta/Baja/Baja solicitada en fecha XXX), el título (título del producto asociado a la edición), el tipo de producto (internacionalizado: curso /clases one-to-one/ clases one-to-two / clases one-to-many), el tipo de pago (periódico/por clase) y el precio.   La funcionalidad estará disponible para: - Un estudiante mayor de edad (para consultar sus propios datos) - Un tutor de un estudiante menor (para consultar los datos del menor) - Un administrador (para consultar los datos de cualquier estudiante)  Añadir una nueva entrada al menú lateral del estudiante para ver esta sección.;F;3;3;
192;"[Gestión] Detalle de un movimiento del monedero. En la lista de movimientos de un monedero, al pulsar en cada uno de ellos, se desplegará el detalle del movimiento correspondiente. Creo que lo más simple, manteniendo la estructura de paneles desplegables actual, sería que el despliegue cargue la consulta correspondiente.  - Para una recarga se mostrará el tipo de método de pago (paypal, etc.), y si es una transferencia (atributo source distinto de null) se mostrará también el usuario del que procede la transferencia (algo como ""Transferencia realizada por XXX""). - Para un pago se mostrará un detalle que dependerá del tipo de operación:   - Para un pago de curso, se mostrará el título del curso que se ha pagado. (""Pago del curso <titulo_curso>"") **   - Para un pago de clase, se indicará la clase que se paga (""Pago de la clase de 26/05/2021 16:30"")   - Para una transferencia, se indicará a quién se realiza la transferencia (""Transferencia de saldo a XXX"")   - Es posible que en el futuro queramos añadir enlaces específicos a los detalles de curso/clase/usuario. Pueden incluirse los ids correpondientes en el DTO o dejarlo pendiente para una issue posterior.   ** Es necesario añadir una referencia a Product dentro de Edition, para recuperar el título del producto desde la edición. Este sería el campo a mostrar aquí.";F;4;4;
190;[Gestión] Mejoras en validación de referencias. Añadiremos las siguientes mejoras en la validación del formulario de creación/edición de referencias: - Marcar los campos obligatorios en el formulario (esto para todos los perfiles) y revisar que la validación solo activa el botón de guardado cuando estén cubiertos. - Añadir la opción de eliminar el fichero actual (solo para administradores, que son los que pueden verlo y subirlo). - Validar que, si se añade un fichero, el estado no puede ser preliminary, y viceversa.;F;2;4;
189;"[Gestión] Como administrador, quiero solicitar una referencia para un profesor. La lógica es la siguiente:  - El administrador, entrando en el listado de referencias de un profesor, debería tener para cada referencia (que esté en estado PRELIMINARY) un botón que le permita ""solicitar"" la referencia. El icono asociado puede ser ""send"", por ejemplo. - En el servidor se llamará a un método nuevo en mailService, que puede llamarse requestReference, que necesita la información de la referencia y el profesor para el que se pide. Está pendiente definir el formato final de este mail, así que por el momento dejaremos un ejemplo mínimo:   - Definir en src/main/resources/templates un template `requestTeacherReference.html` o similar (son plantillas de Thymeleaf). Puede añadirse en el body un texto básico, que diga algo como ""Estimado ${nombre de la persona en la referencia}. Escribimos para solicitar referencias de ${nombre completo del profesor}, que nos ha indicado sus datos. Por favor responda a las preguntas planteadas"". Puede copiarse cualquier otra plantilla y reemplazar el body por el párrafo que indico.    - La plantilla correcta para el email se definirá más adelante, y probablemente incluirá un archivo adjunto, por lo que esta primera versión puede ser muy simple. Con #{} se marcan textos internacionalizados que se pueden añadir en los ficheros messages.properties (src/main/resources/i18n). Con ${} se accede a valores que se establecen en el contexto de la plantilla (usar como referencia el resto de métodos de MailService). - El método requestReference debe establecer en el contexto las variables necesarias (nombre del contacto, nombre del profesor que ha subido la referencia) y cubrir la plantilla. El destinatario de la referencia será el email indicado en la propia referencia.";F;2;4;
187;[Gestión] Uniformizar campos de fecha. Los campos de fecha no se ven de forma uniforme en diferentes vistas de perfil, ni entre diferentes campos en la misma vista.  Propongo: - Utilizar por defecto el formato corto (26/05/2021) - Revisar los componentes que muestran los detalles de perfil (PersonalInfoTab, Profile) y asegurarse de que todos los campos (hay dos por formulario, fecha de nacimiento y expiración de DNI) siguen el formato adecuado.;LF;4;3;
186;"[Gestión] Ajustes en lista de movimientos. Dentro del monedero de un usuario (MovementsList.vue, accesible como estudiante/tutor en wallet->movements): - Añadir un título a la página (""Lista de movimientos"") - Formatear los campos de importes como moneda (dos decimales, y símbolo de € al final) - Formatear las fechas en formato corto.";LF;3;4;
185;"[Gestión] Como profesor, quiero dar de alta / editar una referencia en el sistema. Como profesor candidato/registrado, quiero añadir una nueva referencia para su validación en el sistema.  - Añadir un botón de ""Add"" en la página que muestra el listado de referencias - Crear el componente para el formulario de creación/edición.    - El formulario debería mostrar incluir todos los campos excepto el estado y el fichero.   - El estado por defecto en la creación será PRELIMINARY.  - Añadir un icono de edición que redirija al formulario de edición   - El formulario, para un profesor registrado, mostrará los mismos campos que en la creación (el estado no cambiará si el usuario es profesor).   - Si el usuario es administrador, podrá añadir el fichero asociado y también cambiar el estado. Creo que puede añadirse una prop al componente que gestionar el formulario, que determine si se incluyen estos dos campos, a fin de poder reutilizar el mismo componente en ambos casos.";F;3;4;
184;[Gestión] Referencias de un profesor. Un profesor (candidato o registrado) podrá ver su lista de referencias, de forma muy similar a como ahora mismo puede ver su lista de méritos. Habría que incorporar esta funcionalidad en la pestaña de referencias (ReferencesTab), reemplazando la vista mock actual.  Visualmente se mostrará la información como un listado que puede ser similar al de méritos. Habrá botones para editar y borrar en cada fila, cuya funcionalidad se completará en otras issues.  De cada referencia, un profesor verá todos los siguientes atributos excepto el fichero. Es decir: nombre, posición, compañía, email, teléfono, estado (recordar internacionalizar los mensajes de los diferentes estados).  Un administrador, cuando acceda a las referencias de un profesor, tendrá funcionalidades adicionales. En particular, en el listado podrá descargar el fichero si existe (añadirlo en esta issue, solo para un administrador) y tendrá acciones adicionales que podrá realizar (se añadirá en issues posteriores).;F;4;2;
182;"[Gestión] Como administrador, quiero borrar un producto. Desde la lista de productos, un administrador podrá ""eliminar"" un producto cualquiera. La funcionalidad será similar a los borrados de cualquier otro listado de la plataforma (icono de borrar, popup de confirmación, si se acepta borrar la entrada).  Comprobación adicional: un producto solo podrá borrarse si está en cualquier estado que no sea PUBLIC.  En el servidor hay que comprobar que el usuario actual es administrador y el estado del producto. En la práctica no se borrará el producto, sino que se establecerá la fecha actual como dateEnd (con esto dejará de aparecer en los listados, pero pretendo gestionarlo en una issue separada)";F;4;4;
181;"[Gestión] Mejorar carga de un fichero. Actualmente se permiten cargar ficheros que superan el tamaño máximo definido ahora mismo en el servidor (250 MB). Hay que hacer las siguientes mejoras:  * Comprobar (no sé si esto es posible) el tamaño del fichero antes de subirlo y evitar realizar la petición contra el servidor si este tamaño se supera. En caso de que no sea posible detectar el tamaño del fichero en el cliente, que el servidor lance la excepción al cliente, recogerla, mostrársela al usuario y ""eliminar"" el fichero seleccionado, que el selector quede como si no se hubiese escogido ningún fichero. * En caso de que el fichero sea grande, pero que no supere el límite citado anteriormente, hay que controlar cuando guarda el usuario el formulario. Ahora mismo (en los méritos, por ejemplo) se controla únicamente que el fichero exista para evitar que el usuario guarde el formulario sin que el fichero esté subido, pero esto no sirve. Si yo modifico un mérito que ya tiene un archivo asociado y cambio este archivo por otro de gran tamaño, va a tardar en subirse y podré darle al botón de guardado antes de que este fichero haya terminado.";F;1;3;
179;"[Contenidos] Como gestor de contenidos/profesor registrado, quiero ver la lista de actividades. Un profesor registrado, o un gestor de contenidos, podrá buscar en la lista de actividades disponibles en el sistema.  Cambios a realizar: - Añadir al menú de contenidos (contentEditorMenuItems.vue) una opción de listado de actividades, que dirigirá a esta página - Por defecto el listado mostrará las actividades con resourceType ""ACTIVITY"". En el futuro habrá un listado similar para los ""contenidos multimedia"", que serán los de tipo imagen/vídeo/etc., y para los enlace externos, que serán de tipo LINK. La parte servidor podrá reutilizarse para todas ellas, dado que solo cambiará el filtro de búsqueda (ver #174) - Será necesario incluir filtros de búsqueda: por idioma, nivel, tema (de vocabulario/gramática/skill), tipo de actividad (esto puede delegarse a otras issues) - El listado mostrará y los detalles básicos de cada actividad (nombre, descripción, idioma, nivel, tipo), enlace para ver detalle y borrar (esta lógica se delegará a otras issues).";F;3;4;
177;[Gestión] Recarga con Paypal. Recarga de monedero con Paypal:  Como referencia he subido una versión mínima que contiene un pago con Paypal en !154. Integra los Smart Buttons de Paypal y realiza la operativa en servidor (esto no sería necesario para estos pagos, podría hacerse directamente en cliente, pero las peticiones más complejas se harán en servidor por lo que ya propongo hacerlo siempre de esta forma). De !154 puede reutilizarse la parte de configuración en servidor, los métodos de PaypalService (que hay que completar) y parte de la lógica/configuración del cliente (habrá que integrar lógica similar en la página de pagos actual).  El funcionamiento debería ser similar al siguiente:  - Al seleccionar el método de pago Paypal, se mostrará el botón estándar de Paypal, de forma que la interacción se realice usando ese botón en lugar del estándar de pago (si esto supone algún problema comentarlo, podemos usar nuestros propios botones en lugar de los Smart Buttons aunque nos obliga a gestionar las redirecciones a mano).  - Al pulsar en el botón de Paypal se debería llamar al servidor como hasta ahora. El botón de Paypal proporciona un evento en el que se puede añadir esta lógica. - En el servidor, si el método de pago es Paypal, se llamará a la api de Paypal para crear el pago y se creará como pendiente. El método en !154 debería mejorarse para recibir el importe seleccionado, y cubrir los datos del usuario. - En PaypalService debería comprobarse que no haya errores en la creación (todo es correcto si la respuesta es 201 y el estado es CREATED). En ese caso, se devuelve un id de transacción de Paypal, que debe almacenarse en el WalletCharge (usando el campo genérico de referencia, o si se prefiere un campo adicional paypalId) y devolverlo al lado cliente para que autorice el pago.  - En el lado cliente, al recibir este id de retorno, se abre la pasarela de pago de Paypal. El usuario introduce ahí sus datos y puede confirmar el pago (ver usuario de prueba al final). Debería controlarse onError y onCancel con mensajes adecuados. - Si la autorización del pago es correcta, se invocará el método onAuthorize en el cliente, en el que hay que llamar al servidor para completar el pago (operación capture).  - En el servidor hay que comprobar que la operación se complete correctamente y que los importes sean los mismos indicados inicialmente, y si es así el pago se marca como realizado.   Comentarios adicionales:  - En teoría es sencillo incorporar un botón de Paypal como componente Vue (ver [aquí](https://developer.paypal.com/docs/business/checkout/configure-payments/single-page-app/)). Al hacer pruebas en !154 no conseguí hacerlo de esa forma, tal vez por algún detalle de Vue que se me escapó, y lo integré de forma más tradicional. - El código de ejemplo en !154 es un remix de los ejemplos de Paypal y código anterior. Referencias, por si algo no está claro:   - [Paypal server integration examples](https://developer.paypal.com/demo/checkout/#/pattern/server)   - [Orders API](https://developer.paypal.com/docs/api/orders/v2/)   - [SDK documentation](https://developer.paypal.com/docs/api/quickstart/) (necesaria para configuraciones más avanzadas en el futuro)  - Usuario/contraseña de Paypal para realizar pruebas de pago:   - sb-nbisl6046511@personal.example.com   - ePA@Uy2c;F;3;4;False
174;"[Gestión] Modelo de datos de actividades. Es necesario modificar el modelo de datos de `Activity` para que permita gestionar diferentes tipos de recursos, que no sean necesariamente actividades H5P.  Cambios: - Añadir un atributo ""resourceType"" (enumerado, con valores IMAGE, VIDEO, DOCUMENT, ACTIVITY, LINK) - Añadir los siguientes atributos:   - summary - Resumen para los documentos   - thumbnail - Para vídeos (y potencialmente imágenes), será un segundo File asociado a la actividad.   - duration (horas, min, segundos) - Para vídeos.    - link - Url para un recurso externo.";F;3;4;
173;"[Gestión] Como gestor de contenidos, quiero gestionar las actividades de una lección. Deberíamos tener la opción de añadir/quitar actividades a una lección.   La funcionalidad de añadir debería permitir: - Buscar entre la lista de actividades del sistema (necesitaremos un buscador que permita buscarlas por idioma-nivel, tema, tipo; este componente evolucionará en el futuro para permitir buscar por nuevos parámetros de las actividades) - Asociar una puntuación máxima y tiempo máximo.  La funcionalidad de eliminar simplemente desasociará de la lección.  La funcionalidad de ver detalle por el momento puede mostrar los detalles básicos de la actividad (nombre, descripción, y descarga de fichero).";F;4;4;
172;"[Gestión] Transferencia de saldo. Como tutor, quiero poder transferir saldo de mi propio monedero al monedero de un alumno infantil al que superviso.  - Añadir un botón ""Transferir"" en la vista de saldo de mi monedero. - Se verá un formulario en el que podré escoger el importe (como máximo lo que tenga actualmente de saldo) y el alumno - El método en el servidor puede recibir el tutor, el alumno y el importe. De esa forma si en el futuro se decide añadir la misma funcionalidad desde la vista del monedero del estudiante podremos reutilizarlo.  - Internamente:   - Se creará en el monedero del tutor un pago (WalletPayment), con fecha actual, y tipo transferencia, por el importe seleccionado   - Se creará en el monedero del estudiante una nueva carga (WalletCharge), con fecha actual, por el importe seleccionado. Creo que deberían mantenerse relacionadas, por lo que añadiría un atributo adicional en WalletCharge que referencie al WalletPayment del que sale (solo se cubrirá con esta operación de transferencia, en el resto de casos estará a null).";F;3;4;
170;[Gestión] Ajustes en vista de méritos. La visualización de los méritos (diplomas) de un profesor puede simplificarse, por los datos que contiene, para ver los datos en formato de lista-tabla (tal y como ahora se ve la información en la sección de referencias, o en los lisatdos de usuarios a los que accede el administrador).  Adicionalmente: poner en mayúsculas la primera letra de los campos en los ficheros de i18n, para que sea consistente con otros formularios.;F;3;3;
169;"[Gestión] Recarga de monedero. Aplicable a un estudiante (mayor de edad, sobre su propio monedero) o como tutor (sobre su monedero o sobre el de un estudiante que supervisa).  Añadir un botón a la vista de saldo para ""Recargar monedero"". Esto llevará a un formulario en el que podrá seleccionar un importe (definir un parámetro para el valor mínimo y máximo, por ejemplo 5€ - 200€) y un método de pago (por el momento Paypal y Tarjeta).  En este formulario se engancharán las pasarelas de pago en el futuro. La funcionalidad inicial puede simplemente añadir la recarga (`WalletCharge`) a la base de datos, como confirmada.  Cambio necesario en el modelo: - La clase WalletCharge debería tener un atributo `PaymentMethodType` (el enumerado que existe ahora en `PaymentMethod`)";F;4;4;
168;[Gestión] Ver la lista de movimientos en un monedero. Un estudiante/tutor (sobre su propio monedero), un tutor (sobre el monedero de un estudiante que supervisa) o un administrador, deberían poder ver la lista de movimientos en el monedero correspondiente.   Los movimientos incluyen tanto recargas (WalletCharge) como cargos (WalletPayment). Para cada movimiento, debería mostrarse el tipo (recarga o pago), el importe y la fecha.   Propuesta: - Utilizar un único listado, que agrupe ambos tipos de movimiento en una única vista. - Distinguir claramente recargas de pagos (añadiendo un símbolo que indique el tipo, y poniendo los importes en negativo para los pagos). - Dado el número de potenciales entradas el listado debería estar paginado (no sé cual es la solución más cómoda con la infraestructura actual. Mi solución para esto sería definir una vista y hacer las consultas paginadas estándar sobre ella).  Se añadirán en issues posteriores accesos para ver el detalle de cada movimiento.;F;3;3;
165;"[Gestión] Como administrador, quiero marcar productos como disponibles o no disponibles.. Desde el listado de productos, añadir iconos para ""Activar"" o ""Desactivar"" un producto. Estos botones simplemente cambiarán el estado: activar lo pasará a PUBLIC (solo se podrá hacer si no está ya en ese estado) y desactivar lo pasará a DISABLED (de nuevo, solo si no está ya en ese estado.  Visualmente, y a nivel de comportamiento del interfaz, debería ser similar a la funcionalidad de validar un mérito de un profesor (validateDiploma en EducationTab.vue): mostrar el botón, con un icono que dependerá del estado, con un  (propongo usar ""eye"" y ""eye-off"" como iconos, y ""Make public""/""Disable for the public"" como texto. Habría que ajustar: - Usar el nombre del estado, y no el id, para las comparaciones. - Mostrar los textos como un tooltip y no dentro del botón (como se hace para los iconos de StudentCandidateList).  En el servidor simplemente se actualizará el producto con el nuevo estado (comprobando previamente que el usuario que hace el cambio sea administrador).";F;1;4;
164;[Gestión] Como administrador, quiero crear/editar un producto. El formulario permitirá seleccionar casi todos los campos del producto. Consideraciones:  - El estado del producto por defecto será DRAFT. - Si el producto es de tipo ad hoc, no será obligatorio indicar un curso asociado. Si es de tipo curso, el curso será obligatorio. - Si el producto es de tipo ad hoc, no se mostrará la fecha de inicio y de fin. - En el mismo formulario se podrán indicar las tarifas asociadas al producto. Funcionarán de la siguiente forma:   - Cada tarifa indica el precio para un rango de estudiantes. Debería comprobarse que los rangos no se solapen entre si, ni superen el mínimo y máximo indicados para el producto. Los números de estudiantes no serán obligatorios, solo el importe lo será.   - Si el producto es de tipo curso, los pagos serán por defecto mensuales. Si es de tipo ad hoc, los pagos serán por clase. - Campos obligatorios:    - Titulo, tipo, estado (por defecto:DRAFT), duración de las clases (25/50 minutos), clases por semana, nivel. Al menos una tarifa   - Si es de tipo curso: curso, fechas de inicio y fin.  Todos los campos serán editables, con las mismas comprobaciones que en la creación.;F;2;4;
163;"[Gestión] Como administrador, quiero ver la información de un producto. Debería mostrarse la información detallada del producto. Si el producto tiene un curso asociado, mostrar un enlace a la ficha del curso. La ficha debería incluir: - Tarifas asociadas al producto (al final del todo, en un apartado ""precios""). Si solo hay una, mostrar directamente el precio, si hay varias, mostrar el listado ordenado por número de estudiantes)";F;1;4;
162;[Gestión] Como administrador, quiero listar los productos de la plataforma. Puede utilizarse una vista de tabla paginada similar a la que hay ahora en `ProductListList`. Haría los siguientes cambios:  - (Seguro) Como campos básicos mostraría solo el nombre, el tipo de producto, el nivel (visto como idioma/nivel), el estado y la fecha de inicio y fin.. - (Si resulta simple, si no se delega a otra issue) Añadir buscadores (además del genérico) que permitan filtrar por tipo y por estado (con selectores).  Puede añadirse el enlace como entrada adicional al menú de listas del administrador.  Esta vista es propia del administrador, pero las funcionalidades de listado de productos no lo son (habrá una página pública en la que podrán verse los productos también, pero se mostrarán de una forma más bonita para usuarios finales). Esto significa que en el lado servidor no es necesario comprobar el rol para listar los productos o ver su detalle (si lo será para editar/borrar, que se completará en otras issues);F;3;4;
161;"[Gestión] Como estudiante/tutor, quiero ver mi información económica. - Renombrar la entrada ""Payments"" a ""Monedero/Wallet"". Creo que será más práctico hacerla desplegable, con las entradas hijas ""Saldo"" y ""Movimientos""  - La entrada de ""Monedero"" tendrá una vista básica que permita ver el saldo del usuario (por el momento, solo se mostrará un saldo y una fecha de caducidad del saldo). En issues posteriores se añadirán nuevas funcionalidades al monedero.  Observaciones  - El comportamiento es similar para estudiante y tutor, y el wallet está asociado a userdata. Pueden añadirse endpoints específicos para cada caso con su comprobación si resulta más práctico, o añadir un único endpoint que compruebe todos los permisos. - Las funcionalidades de monedero no estarán disponibles para alumnos menores de edad (así como algunas otras). Idealmente debería definirse un control especial que permita ocultar toda la sección a los alumnos menores de edad (serán sus tutores, en todo caso, quienes accedan a su monedero). Lo comento pero creo que puede ser más práctico resolverlo en una issue separada.";F;4;4;
160;[Gestión] Como profesor, quiero editar mi cv.  En la vista de CV de un profesor, añadir:   - Un símbolo de borrado, para eliminar el CV existente (de nuevo, si el profesor ya tiene CV asociado)   - Un botón de actualizar (puede reutilizarse el que hay ahora para añadir), que permitirá añadir un nuevo CV o editar el existente.  Servidor: - Definir en TeacherResource los métodos para editar/eliminar un cv (puede utilizarse la misma url usada para recuperarlo, pero con putmapping y deletemapping). Definir los métodos correspondientes en el service:   - Al subir un nuevo CV, borrar el fichero antiguo si lo había y añadir el nuevo   - Al borrar el CV, borrar el fichero antiguo si lo había.;F;1;4;
159;"[Gestión] Como profesor, quiero ver mi cv. En la pestaña ""Education"", un profesor ahora mismo puede añadir sus méritos. Faltaría permitirle que actualice también su currículum. La idea es la siguiente:  Cliente: - Añadir en la sección de CV una vista que contenga:   - Un botón para descargar el fichero del CV, si el profesor ya tiene CV asociado (atributo teacher.cv)  Servidor: - Añadir en TeacherResource un método en la url /{id}/cv que permita descargar el fichero asociado al cv de un profesor. Será necesario añadir el método también en teacherService y TeacherServiceImpl (puede utilizarse como referencia lo hecho tanto en el resource como en el service para el fichero de un mérito: se comprueban los permisos y se recupera el fichero utilizando fileService.   En issues posteriores se añadirá:   - Un símbolo de borrado, para eliminar el CV existente (de nuevo, si el profesor ya tiene CV asociado)   - Un botón de actualizar (puede reutilizarse el que hay ahora para añadir), que permitirá añadir un nuevo CV o editar el existente.";F;4;4;
149;[Contenidos] Eliminar una wordlist. En el listado de wordlist habrá un icono de borrado (similar al que hay en los listados de usuarios que ve el administrador (p.ej. `studentList.vue`). Este icono pedirá confirmación, y si se acepta borrará la wordlist. Servidor: al borrar la wordlist se eliminarán la propia wordlist, y deberían borrarse en cascada todas las palabras que tiene asociadas.;F;1;4;
147;[Gestión] Como gestor de contenidos|profesor registrado, quiero ver el detalle de una unidad de un curso. Propuesta (si no resulta complejo): - Añadir en la vista básica de un curso, para cada unidad, un icono que permita desplegarla, y que consulte la información relevante en ese momento (para no cargar todas las unidades al inicio).  La vista de detalle de una unidad incluiría la lista de lecciones que contiene, y las actividades asociadas a cada lección;F;3;4;
144;[Gestión] Como profesor, quiero eliminar un mérito. - En el listado se mostrará un icono de borrado para cada mérito, que pida confirmación (similar a como se hace en los listados de usuarios).  - El borrado del mérito implica eliminar el mérito en si y el fichero asociado. - Esta funcionalidad solo estará disponible si el mérito está en estado UNCHECKED.;F;3;4;
143;"[Gestión] Mejoras en formulario y listado de méritos. - El componente de selección de ficheros debería mostrar el nombre del archivo seleccionado una vez lo esté, para que esté claro que hay uno. - Todos los campos del formulario serán obligatorios (añadir validación en el cliente, hay ejemplos en los formularios de perfil). - (Esto debería ser innecesario por la comprobación anterior, pero podemos mantenerla igualmente) En el listado de méritos, solo debería mostrarse el icono de descarga si el mérito tiene un fichero asociado. - El estado del mérito debería mostrarse de forma internacionalizada. Para esto añadimos los mensajes a los locales y se utiliza un mensaje internacionalizado asociado a cada valor posible, como se hace para genres, timezones, etc. en `Profile.vue`. Los valores posibles inicialmente serán UNCHECKED (""Unchecked"") CHECKED (""Checked"") VERIFIED (""Verified""), pueden añadirse todos juntos en esta issue (se utilizarán en issues posteriores).";F;4;3;
139;[Gestión] Mejoras en ficha/formulario de admin/tutor/gestor de contenidos. Ajustar las vistas de consulta y edición del perfil de los usuarios genéricos, que no son profesores ni estudiantes (todos ellos están basados en los mismos componentes genéricos `Profile`y `ProfileEdit`).  - Organizar los campos de forma similar a estudiantes y profesores en la vista de perfil - En el formulario de edición:   - Organizar los campos de forma similar al resto de usuarios   - No se permitirá editar el login (no se podrá en ningún caso);F;4;3;
138;[Gestión] Refactorizar estructura de componentes de contenidos. Una vez se cierren las issues relacionadas con los contenidos (ahora mismo wordlist y cursos/units), habría que recolocar los componentes del cliente, ya que ahora mismo están todos en `/mockups/admin/contenteditor`, que estaba pensado para contener únicamente lo relacionado con los usuarios con rol `ROLE_CONTENT_EDITOR` en las vistas de administración. Sugiero mover los componentes de wordlists y cursos/units a otro paquete, como por ejemplo `/mockups/content-cloud/wordlist` y `/mockups/content-cloud/course`;F;2;3;
136;"[Gestión] Como gestor de contenidos|profesor registrado, quiero gestionar las unidades de un curso. Propuesta: - Añadir un botón de editar /eliminar en cada unidad, que permita editar su nombre o eliminarla. - Añadir un botón ""Nueva"" que añada una nueva unidad al final de la lista.";F;2;4;
135;[Gestión] Como gestor de contenidos|profesor registrado, quiero editar los datos de un curso. Propuesta: desde la vista de detalle de un curso, tener un botón que permita editar los datos básicos (nombre, descripción, curso/nivel), sin necesidad de cambiar de pantalla (añadir un componente visual para editar estos datos, y al guardar recuperar la vista normal).;F;3;4;
134;[Gestión] Como gestor de contenidos|profesor registrado, quiero ver detalle de un curso. La vista de detalle puede mostrar por defecto la información básica del curso y la lista de unidades. La idea es que en esta misma vista se pueda expandir el contenido de cada unidad para ver todo su contenido, pero en la carga inicial solo se verán los datos mínimos de las unidades (nombre) También desde esta misma vista se podrá realizar la edición básica de unidades (añadir una nueva, eliminar, editar su nombre...) (a realizar en otras issues);F;3;4;
133;[Gestión] Como gestor de contenidos|profesor registrado, quiero eliminar un curso. ;F;3;4;
132;[Gestión] Como gestor de contenidos|profesor registrado, quiero crear un nuevo curso. Propuesta: incluir en el formulario de creación los datos básicos (título, nombre, selección de idioma-nivel) y permitir también indicar un número de unidades que contiene. La versión más simple sería que se indique este valor y en servidor se creen las unidades, alternativamente pueden añadirse las unidades en cliente (para que pueda editarse su nombre) y enviar todo al servidor;F;3;4;
131;"[Gestión] Como gestor de contenidos/profesor registrado, quiero listar los cursos del sistema. Propuesta:  - Modificar el menú que ahora mismo existe para el content-editor, y convertirlo en menú de ""Contenidos"":   - Tendrá acceso a las diferentes secciones de la nube de contenidos   - Dependiendo del perfil de usuario se ocultarán algunas opciones (por ejemplo, las listas de palabras quedarán para los editores de contenido, mientras que los profesores registrados podrán acceder al listado de cursos)  - Añadir un listado de cursos, que mostrará solo la información básica (curso, descripción, nivel e idioma). Los atributos minStudents y maxStudents desaparecerán en la próxima versión del producto, pero pueden eliminarse a mano en la versión actual.";F;4;4;
129;"[Gestión] Como estudiante, quiero añadir/quitar un tutor. Ahora mismo un estudiante menor de edad añade sus tutores en el primer formulario y no puede editarlos. Como es necesario realizar controles específicos, creo que resulta más práctico que a partir de ese punto se gestionen los tutores por separado en lugar de gestionarlo en el mismo formulario inicial.  La idea sería, desde la vista de tutores de un estudiante (menor de edad, que son los que tienen tutores): - Tener un botón de añadir que permita indicar los datos básicos de un tutor nuevo (de la misma forma que en el formulario de guest)   - El comportamiento sería el mismo que en el formulario de guest: se crea un Tutor y se envía un enlace de activación. - Tener un botón para ""quitar"" un tutor. Aqui añadiría varios controles:   - Solo se puede quitar un tutor si no está vinculado a un usuario (es decir, tutor.userData es nulo), para evitar que se hagan cosas extrañas.   - No se puede eliminar el último tutor.";F;4;4;
128;[Gestión] Asociar un nuevo estudiante a un tutor. **Solo como administrador**, en la ficha de alumnos supervisados por un tutor, quiero tener la opción de vincular un nuevo estudiante.  - Mostrar un diálogo para escoger estudiantes (puede usarse como referencia `SupervisingTab`, que hace algo similar pero para profesores. Habría que hacer lo mismo para estudiantes. Debe añadirse también un selector de relación para poder indicar la relación entre el estudiante y el tutor. - Añadir la asociación. Esto implica en el servidor crear una entrada `Tutor` que tendrá   como estudiante el deseado, la relación indicada y como userData el del tutor al que se vincula.;F;4;4;
127;"[Gestión] Desasociar un estudiante de un tutor. Desde la ficha de un tutor, tenemos acceso a la lista de estudiantes que supervisa.  Para cada estudiante, habría que añadir un botón de ""Desvincular"":   - En el servidor: se buscará la entrada `Tutor` que está asociada al `UserData` del usuario actual, y establecerá ese valor de `userData` a null (es decir, en el estudiante seguiría apareciendo una entrada para el tutor, pero no estaría vinculada a ningún usuario. Añadir los métodos en TutorResource y TutorService.";F;4;3;
123;[Gestion] Refactorizar búsqueda de un string mediante especificaciones. En la issue #64 se ha implementado una nueva forma para buscar un string en los atributos de las entidades que están relacionadas con otras. Por ejemplo: las Wordlist están relacionadas con Level, por lo que con esa nueva implementación, además de buscar por el atributo `name` de Wordlist, también se busca por `name` de Level, pero además de una forma en la que no hace falta crear nuevos *_utils*, tal y como se venía haciendo para los usuarios (User, UserData, Teacher, etc.) hasta ahora.  Por tanto, hay que cambiar esos *_utils* por la nueva implementación, que nos parece mucho más limpia.;F;1;3;
121;"[Gestión] Ajuste en vista de perfil de profesor. Formulario de edición:  * Colocar los campos de la misma forma que en el formulario de estudiantes. * Ajustar el título (nuevamente, usando el formulario de estudiantes como referencia) * Añadir los campos de ""aceptar emails/whatasapp/llamadas"" al final del formulario (usar el formulario de estudiante como referencia).  * Añadir un cuarto campo checkbox para indicar si acepta ser sustituto. Será necesario añadirlo al DTO y modificar el servidor para que el campo se guarde. * Recolocar los botones de guardar de la misma forma que en el formulario de estudiantes  Vista de detalle (ficha)  * Añadir campos que faltan en los datos personales * Colocar el botón de edición en la parte superior * Eliminar de la vista la valoración (estrellas), el campo ""link to video"" y el campo ""level or levels""";US;4;4;
119;[Gestión] Ajustes en perfil de estudiante. Propuesta de cambios  Formulario de edición: - Añadir nif y fecha de expiración (no serán obligatorios). Pueden añadirse debajo del bloque de campos de dirección. - Mover timezone e idioma a la parte inferior del formulario, encima de los checkboxes, ya que casi nunca se editarán.  Vista de detalle (ficha) - Añadir campos que faltan en los datos personales (nif y fecha de expiración, idioma) - Añadir las indicaciones de cosas que acepta (whatsapp, mail, llamadas), entiendo que encaja en la sección de datos de contacto o al final del todo. - Eliminar el balance;F;4;4;
119-2;[Gestión] Ajustes en perfil de estudiante. - Colocar el botón de edición en la parte superior;F;4;3;
118;[Gestión] Como profesor, quiero descargar los ficheros asociados a mis méritos. En el listado de méritos, añadir un enlace para descargar el fichero asociado. Para ello habrá que definir un endpoint específico, del estilo `xxxxx/merit/:id/file`. En la parte servidor se comprobará el usuario (solo el propio profesor o un administrador pueden acceder) y se dvolverá el fichero, de forma similar a como se hace ahora con la fotografía de perfil de un usuario.;F;3;4;
117;[Gestión] Como profesor, quiero añadir un nuevo mérito (y editar uno existente). Desde la lista de méritos, el botón para crear un nuevo mérito dirigirá a un formulario en el que se podrán indicar los campos básicos (todos excepto el estado) y asociar el fichero. Puedes partir de lo existente en modules/merit/components, la idea es tener un componente como MeritForm que se pueda reutilizar tanto para crear como para editar méritos.  - La funcionalidad de subida de ficheros es genérica, puede verse el comportamiento en el formulario de perfil (foto de perfil). Se sube el fichero y se guarda un id temporal que se envía con el formulario para asociar el fichero al crear la entidad (en este caso mérito). - En el lado servidor debe controlarse lo siguiente:   - Solo se completará la acción si el usuario al que se asocia el mérito debe ser el propio usuario profesor, o si el usuario actual es administrador.   - El estado inicial del mérito al crealo será pendiente. Este campo no será editable nunca en el formulario (en la edición se mantendrá el valor anterior);F;4;4;
115;[Gestión] Organizar campos de perfil de admins, gestores, tutores para que sean similares a profesores/estudiantes. Reorganizar la vista `Profile.vue` para que muestre el nombre del usuario en el título, y los campos colocados de forma similar a como se puede ver en la vista de un profesor o un estudiante. Al reutilizarse la vista, el cambio debería quedar aplicado a los usuarios de todos los perfiles indicados.;F;4;3;
112;[Gestión] Modificar comprobación de permisos en el router. Ahora mismo el router solo es capaz de comprobar el acceso a una ruta con un solo rol.  Habría que modificar el router para que se le pueda pasar un listado de roles y que compruebe si tiene acceso a alguno de ellos para poder dar acceso a la vista.;SE;3;3;
111;[Gestión] Mejoras en formulario de registro de tutor. El formulario de registro como tutor `TutorRegister` al que se accede mediante enlace por email después de que lo registre el alumno no es uniforme con otros formularios posteriores: - Idealmente debería refactorizarse, por ejemplo reutilizando `GenericProfileForm`, para poder reordenar campos y ajustar la visualización de forma común más adelante.;F;3;3;
110;[Gestión] Como tutor de un estudiante, quiero acceder a la información de su perfil. Un tutor tendrá acceso por defecto a (casi) todas las secciones del perfil de un estudiante, con pequeñas limitaciones. Debería incorporarse un mecanismo de control similar al que hay para el acceso de administrador, para que el tutor tenga acceso a la información del estudiante por id.;SE;4;4;
108;[i18n] Internacionalización de emails. Los emails que se envíen a los usuarios deberían enviarse en el idioma por defecto del usuario destinatario. Ahora mismo entiendo que se toma el locale por defecto de la aplicación, y no se está utilizando mensajes localizados. Dado que las plantillas de emails son provisionales, podemos aplicar internacionalización por el momento solo a alguna de las más sencillas (p.ej. activación de usuario) para validarlo, y completar el proceso en issues futuras.;US;3;4;
107;"[Gestión] Como administrador, quiero ver y editar el supervisor de un profesor. (Complementaria a la funcionalidad ya realizada de asignar profesores a un jefe de estudios) - Desde la vista de datos básicos de un profesor (candidato o registrado, que no sea jefe de estudios), debería mostrarse el nombre de su supervisor (jefe de estudios). Creo que puede mostrarse en la parte superior, de forma separada de los campos del usuario. - Como administrador, debería tener la indicación ""Sin supervisor"" o similar si no tiene uno, y poder asignarle uno (con un buscador de jefes de estudios; este buscador puede mostrar solamente los datos básicos de los jefes de estudios según se busca (nombre a mostrar, nombre y apellidos, email?).";F;3;4;
106;"[Gestión] Ver los alumnos supervisados por un tutor. Un tutor, desde su propia sección de perfil, y un administrador, entrando en la información de un tutor, tendrán acceso a la lista de estudiantes de los que es tutor. En el menú lateral de un tutor ya existe una entrada (""Related students"") asociada al componente `StudentListTab`. Este componente debería mostrar una vista básica de los estudiantes que el tutor supervisa.  - Para encontrar los estudiantes asociados habrá que definir un método específico (en `StudentResource`) que los recupere. Los estudiantes asociados son aquellos objetos Student que tienen asociado un objeto Tutor cuyo `userData` es el del tutor que estamos buscando (todos los estudiantes cuyo tutor.userData se corresponda con el usuario de la consulta). - Puede utilizarse, para cada estudiante asociado, una card-view similar visualmente a `TutorInfo.vue` (construir un componente especifico para esto, aunque será preferible que solo incluya el email y teléfono principales, y no los secundarios). El componente de referencia, de los tutores, puede verse entrando como admin en la ficha del estudiante candidato 1 (Tirso). La idea es tener una visualización similar.";F;4;3;
104;[Gestión] Enlaces para baja de usuarios en listados de administración.. Debería incluirse un botón para dar de baja usuarios en todos los listados de administración.  Visualmente puede ser similar al que hay en `UserManagementList`. Debería mostrar un aviso de confirmación, para confirmar que se quiere realizar la baja, y a continuación llamar al endpoint creado en #88 para realizar la baja de forma efectiva.  Los componentes correspondientes a los listados son: - TeacherCandidateList - TeacherRegisteredList - StudentRegisteredList - StudentCandidateList - ContentEditorList - AdminList - TutorList;F;4;3;
98;[Gestión] Menú lateral para tutores. Definir un menú lateral para tutores similar al que existe para profesores o estudiantes. - En la vista de usuario (el propio tutor) tendrá al menos la pestaña de sus datos de perfil y pestañas adicionales para sus medios de pago/monederos y para la lista de estudiantes de los que es tutor (pueden añadirse las entradas vacías). - En la vista de administración tendrá la pestaña de datos de perfil (se completará en #96) y la lista de estudiantes de los que es tutor.  Trabajo: - Contruir una vista `TutorDetail` similar a la de `TeacherDetail` `StudentDetail`, que se aplicará a usuarios con rol `ROLE_TUTOR` y permitirá acceder a sus secciones   - Incluirá una lista de entradas calculadas a través de una propiedad `navBarCalculated`, y definidas en un archivo `navBarItems.js`.    - Inicialmente pueden añadirse entradas en blanco para todos los componentes excepto los correspondientes a la ficha del tutor (ver #96).;LF;4;3;
97;"[Gestión] Listados de administración: omitir usuarios de baja. Los listados de administración (todos los del menú ""Lists"") listarán solo usuarios que sigan de alta (aquellos que no tienen un valor en `UserData.dateEnd` Debería afectar solo a la lógica de los siguientes endpoints en el servidor: - TeacherResource.java: getAll - StudentResource.java: getAll - UserDataResource.java: getContentEditors, getAdminList, getAllTutors Podemos aprovechar la issue para uniformizar los nombres de estos últimos tres métodos.";F;3;3;
95;"[Gestión] Creación de usuarios ""genéricos"" como administrador. El administrador tendrá la opción de crear usuarios de tipo tutor, administrador o gestor de contenidos desde los listados correspondientes.   Propuesta de cambios a realizar: - Modificar el `GenericProfileForm` para soportar la opción de incluir los campos que se usan durante el registro (login/email). Puede hacerse de la misma forma que en StudentForm, con una prop que se utilizará solo cuando estos campos sean necesarios. - Construir el componente que permita realizar el alta. Idealmente debería usarse el mismo componente para los diferentes roles (el único cambio será la authority del usuario que se da de alta, y la redirección posterior). - Definir un método genérico en el servidor para el alta de usuarios. Limitado al rol administrador, y puede comprobarse que no se utilice para los roles student/teacher, que ya tienen sus propias funcionalidades de creación.";F;4;3;true
94;[Gestión] Ajustes en la ficha de perfil como administrador. Al entrar en la vista de perfil de usuario como administrador (es decir, si no estamos editando nuestro propio usuario) el botón de editar perfil apuntará a una url diferente y la funcionalidad de cambiar contraseña no estará disponible.;F;3;3;False
88;"[Gestión] Baja de usuarios. - Añadir un método en `UserDataResource` que permita ""borrar"" un usuario por id. En la práctica, lo que hará este método será marcar el usuario como de baja (estableciendo el valor de `UserData.dateEnd` a la fecha actual).    - Controles: solo se permite la baja si el usuario que se da de baja es el mismo que envía la petición, o si lo hace un administrador.   - La lógica del método de baja puede definirse en `UserDataService`. Quedaría pendiente definir controles adicionales que sea necesario realizar antes de dar de baja al usuario   - Cambios a realizar en la base de datos:     - Establecer el valor de `userData.dateEnd` a la fecha actual     - Establecer `userData.user.activated` a false. - En cuanto estén completos los listados de administración se añadirá el botón de borrar y la funcionalidad de filtrar para mostrar solo los usuarios que estén de alta (esto se hará en otra issue)";SE;4;4;true
80;[Gestión] Mejorar formulario de admin para nuevos estudiantes. Una vez que se cierren las issues https://gitlab.lbd.org.es/lms4.0/webapp/-/issues/71 y https://gitlab.lbd.org.es/lms4.0/webapp/-/issues/55 habría que modificar el formulario de nuevos estudiantes del administrador para añadir la foto de perfil y las validaciones en cliente de los datos.;F;4;3;
78;[Gestión] Añadir reglas al componente BirthdayPicker. Ahora mismo el componente no permite añadirle reglas, por lo que en los formularios no es posible indicar el valor como obligatorio antes de que el usuario guarde sus datos.;F;3;4;
76;[Gestión] Como administrador, quiero añadir/eliminar profesores supervisados por un jefe de estudios. Se haría desde la pantalla en la que puede verse el listado de profesores. Para añadirlos habría que tener un buscador básico por nombre. Buscaría en la lista de profesores (candidatos o registrados) que no tienen jefe de estudios asignado.;F;4;4;
71;[Gestión] Como administrador, quiero crear un estudiante. En los listados de estudiantes, debemos tener un botón para crear un nuevo usuario de tipo estudiante.  El formulario de creación debería incorporar todos los campos que un estudiante invitado tiene que cubrir inmediatamente tras el registro.;F;3;4;
70;[Gestión] Como administrador, quiero crear un profesor. En los listados de profesores, debemos tener un botón para crear un nuevo usuario de tipo profesor.  El formulario de creación debería incorporar todos los campos que un profesor invitado tiene que cubrir inmediatamente tras el registro.;F;3;4;
68;[Gestión] Como administrador, quiero ver la lista de profesores que supervisa un jefe de estudios. Ahora mismo tendría sentido gestionarlo como una entrada de menú lateral para aquellos profesores que tienen el rol adicional de jefe de estudios.;F;3;4;
61;"[Gestión] Como administrador, quiero listar gestores de contenido. (puede utilizarse como referencia la lista de profesores candidatos que está implementada)  - Cliente   - Crear entrada en el router para el listado (client/src/mockups/admin/router.js)   - Construir la vista para el listado (puede utilizarse como referencia el componente `TeacherCandidateList`, los campos a mostrar serán en principio los mismos) - Servidor   - Ajustar la estructura para la consulta de usuarios con el rol de content editor. Dado que las funcionalidades serán muy similares en otros perfiles de usuarios, podrá reutilizarse seguramente la clase `UserDataResource`, proporcionando un método de listado de forma similar a como funciona ahora mismo `TeacherResource`: soporte para búsquedas de usuarios por rol y devolver su DTO correspondiente. El funcionamiento será muy similar al que existe ahora mismo en `TeacherResource.java`: el método de búsqueda básico permitirá listar de acuerdo a una especificación de búsqueda, que incluirá las ""authorities"", y devolverá una estructura paginada. La parte cliente ya tiene soporte para este tipo de estructuras.";F;4;4;
57;[Gestión] Vincular tutor con estudiante. A través de un código recibido por email, un usuario de la plataforma puede vincular su usuario como tutor de un estudiante. Simplemente debe comprobarse que el código es válido y asociar el usuario actual como tutor del estudiante (borrando el código en BD para que no pueda usarse varias veces). Si el usuario no tenía el rol de tutor (p.ej. porque era estudiante) debería asignársele en ese momento.;F;3;4;
56;[Gestión] Registro como tutor. queremos registrarnos con rol tutor. Necesitaremos: - Crear el rol en el modelo - Construir el formulario de registro (incluye el código adicional de tutor que hay que verificar para asegurar que se vincula con un estudiante correctamente);F;4;3;
55;[Gestión] Completar formulario de datos básicos de profesor. - Subir foto de perfil - Validación de campos: añadir validación en cliente de campos obligatorios;F;4;4;
48;[Gestión] Enlace para registro como tutor. Cuando un alumno indique sus tutores, debe enviarse un correo a cada uno de ellos para que puedan registrarse en el sistema y asociar su cuenta con la del estudiante;F;3;4;
46;[Gestión] Como estudiante (candidato/registrado) quiero poder ver mi agenda. Debería tener acceso a una vista (por defecto semanal) en la que aparecerán las diferentes actividades que puedo tener asociadas. Por el momento serán de 2 tipos: - (Un)Availability (horas marcadas como (no)disponible) - Lectures  En este momento no aprecio ninguna diferencia relevante entre el calendario de un estudiante y el de un profesor, por lo que los componentes de la vista y posiblemente los DTOs podrían ser similares:    - Un objeto ScheduleDTO    - Una lista de ScheduledActivityDTO con los elementos y su información asociada:      - (un)Availability: instantes de inicio y fin      - Lectures: como mínimo instantes de inicio y fin, nombre del profesor e id de la clase para crear los enlaces correspondientes.  Acciones a realizar desde este calendario (a ampliar en otras issues) - Añadir un periodo de disponibilidad - Anular un periodo de disponibilidad (i.e. establecer no disponibilidad) - Acceder a la ficha de la clase;F;3;4;
44;[Gestión] Cambiar los listados de teachers y students con los campos/acciones necesarias. Ahora mismo se muestra información básica poco relevante en los listados. Habrá que definir que campos interesan para cada listado y modificar las vistas en función de eso. Por otro lado también habrá que añadir la navegación desde los listados hacia las vistas detalle.;F;1;4;
41;"[Gestión] Modificar la barra superior dependiendo de los roles. Ahora mismo hay un solo componente de menubar, a la vista de que existirán distintos roles que pueden acceder a vistas muy distintas, a futuro se creará un componente que reúse v-list-items dependiendo de los roles que tenga el usuario autenticado  ``` <menubar>   < v-if=""isUserAdmin"" admin-list-item>   <v-if=""isUserTeacher"" teacher-list-item> </menubar> ```  En caso de tener varios roles se le añadirían distintos menús desplegables con las funcionalidades definidas en cada subcomponente para un rol";F;4;3;
39;[Gestión] Refactorizar perfiles de estudiante y profesor. Para simplificar el funcionamiento de los perfiles de usuario, se trasladará el formulario de creación de estudiante/profesor a rutas a parte y, una vez creado, se podrá acceder como hasta ahora al perfil de usuario, que incluirá en la URL el ID del estudiante en cuestión. De esta forma, podemos obtener desde cada componente hijo (formulario, vista detalle, en un futuro calendarios, pagos, etc.) los datos que se necesiten a través de ese ID, sin hacer una única gran petición en el componente padre de todos los datos, que además podrían estar desactualizados.;F;4;2;
30;[Gestión] Terminar de implementar el interfaz de usuario que obliga a cubrir los datos requeridos de mi rol. La issue #7 implementó la primera versión de esta funcionalidad, pero se dejaron aspectos pendientes debido a que necesitaban que se generar un nuevo producto desde la LPS.  Cuando se genere de nuevo el producto de la LPS hay que terminar la parte del cliente y ajustar el servidor a los cambios en el modelo de datos.;SE;2;4;true
23;[Gestión] Como administrador, quiero poder crear un usuario y asignarle roles. ;F;1;4;False
19;[Gestión] Como administrador, quiero poder ver la ficha de detalle de un profesor registrado. ;F;3;4;
15;[Gestión] Como estudiante, quiero poder ver mi perfil completo y rellenarlo. ;F;1;4;
14;[Gestión] Como profesor, quiero poder ver mi perfil completo y rellenarlo. ;F;1;4;
8;[Gestión] Como administrador, quiero poder ver la lista de profesores candidatos. ;F;3;4;