Mass upload de alumnos
Podria llegar a faltar una ventanita intermedia que diga que registros se agregaron bien
y cuales mal (por ejemplo si hay algun alumno duplicado)
Actualizar esquema de la DB con cambios de archivo en Enunciado.
Como SQLObject 0.7.x no tiene hooks para hacer cosas extra al crear la DB
(como crear esas tablas intermedias locas que tenemos), no se puede usar
el tg-admin sql create para crear la base, por eso hay que hacerlo via
el script de SQL doc/schema/schema.sql. Por ahora hay que editar ese
archivo a mano cuando se cambia el modelo :S
SQLObject 0.8 (ya está en Debian) agrega hooks para salvar esa
situación, estuve experimentando pero me tira algunos errores, en cuando
lo arregle mando el parche. Además tiene varias mejoras el SQLObject
0.8 así que la idea sería laburar con ese para evitar más hacks.
Arreglar jsonify.
Arreglar tanto jsonificación de clases propias (las pocas que crea
automáticamente TG) y el jsonify_sqlobject() que no soporta
InheritableSQLObjects. Ver ticket #1307:
http://trac.turbogears.org/ticket/1307
Convertir parametros de CasoDePrueba en un campo de string con validador especial.
Guardar los parámetros como una tupla puede ser cómodo pero al usar Pickle, la
base queda ilegible e inusable desde algo que no sea Python. Por lo tanto, y
porque es más natural ingresar los parámetros como un string al estilo bash, se
creó un nuevo tipo de columna de SQLObject que valida/convierte el string
almacenado en una lista y viceversa, permitiendo usar string o listas
indistintamente, pero siempre almacenándose como string.
IMPORTANTE: Hay que regenerar la DB y tiene un "bug", al editar, los datos de la
DB se "renderizan" como una lista en el formulario, hay que ver una forma de
renderizarlo como en el list/show.
Hacer que formularios sean subclase de TableForm.
Si los formularios son instancias de TableForm en vez de subclases, cuando
quieren usar javascript modifican el atributo *de clase* 'javascript' de
TableForm y termina inyectándose el javascript de *todos* los formularios juntos
en cada formulario renderizado. Por ahora no encontré mejor solución que la
subclase.
Agregar controlador para ABM de enunciados.
Controlador para ABM de enunciados. Tal vez se pueda hacer una superclase para
no repetir tanto código, pero como las personalizaciones van a ser cada vez más
frecuentes, no sé si será de mucha utilidad.
Reutilizar validación de ID y existencia de objetos.
Se mueve la parte de validación de id y de existencia de SQLObjects al módulo
validate de subcontrollers. De esta forma se puede reutilizar esta validación en
otros controladores. En el controlador de docentes se 'bindean' las funciones
con los parámetros de clase y nombre para que sea más simple el uso (tipo
aplicación parcial :).
Bugfix. Los constructores no les gustaban a SQLObject.
Los constructores que necesitaban parámetros obligatorios no le gustó a
SQLObject, así que se tuvieron que poner parámetros None por default (lo que
hace un poco tonto el parche de los constructores en primera instancia).
Sobreescribe constructores para que queden más lindos.
Ahora los SQLObject tienen constructores custom. Por ejemplo se puede pasar
'padron' al alumno (aunque no es ni necesario poner el keyword) y si se pasa un
'password' a alumno o docente, se guarda encriptado a través del constructor
directamente. También se hace que muchos constructores acepten listas de los
elementos que contienen (sólo se agregó esto donde parecía tener sentido).
Manejar bien errores en controlador de docente.
Informar mejor al usuario cuando un id no es válido, o no existe es el objeto,
al editar, activar, ver o borrar docentes.
ABM de docentes.
El ABM de docentes usa decentemente la infrastructura de widgets de TG y es un
buen ejemplo para usar de plantilla para ABM de otras cosas. Además usa docutils
para que las observaciones tengan formato tipo wiki y una función de utilidad
para KID para resumir un campo para que la tabla no se deforme.
Agrega nueva relación ordenada entre Enunciado y Tarea.
Se agrega una relación entre Enunciado y Tarea igual que la relación entre
InstanciaDeEntrega y Tarea. La idea es usar como template estas tareas a la hora
de agregar una nueva InstanciaDeEntrega.