BDD Design - Githubissues

andresmanelli commented 8 years ago

Nota: Los nodos (cuadrados) son nodos de tipo distinto a User y su jerarquía depende de la institución. En este ejemplo se usa una facultad pero podría ser general.

text12364-4-6

Reglas de Usuarios:

Un usuario con relación de super administrador (:SADMINS) puede BORRAR y CREAR todo AGUAS ABAJO. Está dentro de sus posibilidades el:
- Crear o borrar nodos aguas abajo
- Asignar usuarios administradores, i.e., crear relaciones :ADMINS a los nodos o desasignarlos.
- Asignar o desasignar usuarios super administradores a nodos aguas abajo.
- En general, todo lo que puede hacer un administrador, también puede hacerlo un super administrador. NO está dentro de sus posibilidades el:
- Borrar su propia relación de super administrador. Esto debe ser hecho por otro super administrador aguar arriba.
Un usuario con relación de administrador (:ADMINS) puede CREAR todo AGUAS ABAJO, pero sólo puede BORRAR su propia relación de administrador.
Un usuario normal que quiera tener relación especial (e.g., :PROFESOR_JTP) debe ser designado por un administrador o super administrador.

Reglas de Actividades:

Una actividad de tipo periodo se reparte a lo largo de muchos días o semanas.
Una actividad de tipo periodo tiene asignado un ID de periodo.
Si existen actividades individuales (de excepción) con el mismo ID de periodo y el mismo horario que una actividad de periodo, tiene prioridad la actividad individual a la hora de su representación gráfica en el calendario.
Si existen actividades individuales con el mismo horario que una de periodo pero con diferente ID de periodo, son simultáneas y deben tomarse las medidas necesarias en el calendario para su representación correcta.

Reglas de Nodos:

Un nodo es designado como parte de otro en una jerarquía menor mediante la relación :PARTOF

francoa commented 8 years ago

@fcladera pudiste ver esto? Estás de acuerdo?

Si es así, me pongo a crear los métodos que falten en el backend

fcladera commented 8 years ago

Ahí lo vi, está bastante claro!

Igual, en mi opinión, yo sacaría el nodo decano y director. Qué función especial tiene? Por qué habría que diferenciarlo? No es el director de carrera el que va a administrar el sistema, tampoco es el decano.

Otra pregunta, se permiten múltiples ADMIN por Facultad o por Carrera? Múltiples SADMIN?

fcladera commented 8 years ago

No veo muy bien la diferencia entre SADMIN y ADMIN. Hay sólo 1 SADMIN por Facultad o Carrera? Por ahí es algo así?

SADMIN puede crear y borrar cuentas en su mismo nivel de jerarquía. No puede borrar su cuenta, la tiene que borrar un SADMIN de nivel superior. Hay sólo 1 por Facultad o Carrera necesariamente
ADMIN puede crear y borrar cuentas en niveles inferiores de jerarquía. Puede haber 1 o más ADMIN por Facultad o Carrera.

fcladera commented 8 years ago

Profesor es ADMIN de su materia? Profesor_JTP?

francoa commented 8 years ago

La idea del ADMIN es sacarle un poco de carga a SADMIN. Digamoslo así, el SADMIN es el que apagaría los incendios que, inevitablemente, van a generar las personas que puedan crear y borrar contenido en el sistema. A continuación me explico mejor.

El SADMIN es alguien que tiene acceso a todo lo que esté aguas abajo. Puede crear y borrar. Esto quiere decir que si el SADMIN decide que Mecatrónica mañana va a tener una materia que sea Diseño de Cortinas para Interiores, la puede poner. Sería una posición de gran responsabilidad y la idea es que haya pocos SADMINs. 1 por Facultad era por ahí el número que habíamos pensado, aunque es a discutir.

El ADMIN sería más bien alguien que gestiona sólo lo relacionado a su nodo. El ejemplo más claro que se me ocurre sería Susana: el SADMIN le da el ADMIN de la carrera de Mecatrónica. Entonces Susana empieza a cargar todas las materias que corresponden a la carrera y a asignarles ADMINS (los profesores titulares, por ejemplo, y estos irían metiendo al resto del equipo docente), y de esta forma no tiene que hacerlo necesariamente el SADMIN. Además, si hay alguna materia nueva, la carga el ADMIN sencillamente sin tener que esperar a q el SADMIN lo haga.

Lo que habíamos pensado de que el ADMIN sólo pudiese borrar su propia relación ADMIN era para evitar que alguien venga, se equivoque, y por ejemplo borre una materia, con lo que se borrarían todos los horarios asignados y se armaría alto quilombo. Esta responsabilidad recae en el SADMIN.

francoa commented 8 years ago

Lo último es por ahí la diferencia más grande entre ADMIN y SADMIN

fcladera commented 8 years ago

Deduzco entonces que cada nodo requiere un ADMIN? Puede tener varios ADMINS? Al borrar el Admin, se borran todos los nodos que tiene asignados?

francoa commented 8 years ago

No hemos hablado si necesariamente tiene que haber un ADMIN. El hecho de que esté el SADMIN hace que sea un sistema "híbrido" entre lo que está ahora en la facu y lo que queríamos hacer. Tranquilamente puede recaer todo el trabajo en el SADMIN y que lo usen así. No sería lo ideal, tal vez podríamos forzarle al menos un ADMIN.

Supongo que también puede asignarse más de un ADMIN.

Cuando se borra la relación ADMIN (cosa que lo puede hacer el admin mismo) sólo se borra la relación. Sólo el SADMIN puede borrar nodos.

fcladera commented 8 years ago

Perdón por la molestia, pero sigo sin entender esto

Lo que habíamos pensado de que el ADMIN sólo pudiese borrar su propia relación ADMIN era para evitar que alguien venga, se equivoque, y por ejemplo borre una materia, con lo que se borrarían todos los horarios asignados y se armaría alto quilombo. Esta responsabilidad recae en el SADMIN.

El admin puede crear pero no puede borrar nodos aguas abajo? Creo que es mejor hacer que si puede crear, puede borrar. No van a haber muchos ADMINS en teoría. Por ahí la buena diferencia sea que los admins no puedan crear otros admins. Tal vez estoy peeing outside of the jar.

francoa commented 8 years ago

Bueno, es parte de la discusión que hay que tener.

Sólo eso te hace ruido?

fcladera commented 8 years ago

Si, no sé si es que me hace ruido o que no lo entiendo hahaha

andresmanelli commented 8 years ago

Para la fusión de calendarios pensaba esto:

Mantener la relación actual de SUBSCRIBED pero con un parámetro que sea merge_calendar por defecto a true.
Este parámetro verlo reflejado en los checkboxes que mencionaba en #16
Si elegimos no mezclar un calendario, lo destildamos de las checkboxes, pero lo mantenemos en favoritos.

andresmanelli commented 8 years ago

Les parece que los calendarios personales sean SIEMPRE privados? De esa manera nos evitamos problemas de consultas a IDs de usuarios. Sería facil de verificar en el backend si el id enviada en cookie y el id pedido sean los mismos.

Si el ID Cookie es igual al ID pedido -> Return actividades personales
Si el ID Cookie no existe o el ID pedido es distinto -> Devolver solo las actividades relacionadas con :ASOC_TO al nodo del ID pedido.
- Como las relaciones :ASOC_TO solo se crearian hacia nodos que no son User, no se piden nunca calendarios privados.

MecatronicaUncu / Red-Social-Asociacion

BDD Design #131