Petició de millora: logins independents per a tutors

[jaumeteixidor]

Tenim a l'institut pares que no es parlen. Això pot ser un problema de cares al futur, de manera que si un entra una contrasenya per a l'identificador d'alumne, l'altre no pot entrar (a no ser que marqui com que ha oblidat la contrasenya) Podria haver-hi la possibilitat de que els diferents tutors tinguin diferent contrasenya? o que es faci usuari diferent associat al mateix alumne per a cada un dels correus de tutors legals? Per ara hem demanat als pares que s'entenguin entre ells, que és per l'educació del seu fill i bla bla bla, però segur que algun dia en trobem un de torre-collons, i per experiències prèvies, els jutges donen la raó a aquests pares i ens diuen que en tot cas som nosaltres que hem de canviar d'aplicatiu. Aquí ho deixo...

[ctrl-alt-d]

Hola @jaumeteixidor ,

gràcies per la issue, realment això és una limitació que un dia s'ha de solucionar. És molest pels pares haver d'anar recuperant l'accés si l'altre tutor legal canvia la passwd. Es pot treballar així, però seria molt millor un usuari per a cada progenitor.

Fa dos cursos, quan es va començar a escriure l'App per a famílies, ja es va tenir això en compte. Es prioritzava l'aplicació mòbil per sobre del portal perquè hi ha famílies que el tema correu els hi costa. La idea era substituir el portal per App mòbil. L'App estava dissenyada per tal que un tutor legal pogués agregar més d'un alumne (cas de pares amb més d'un fill al centre), també per afegir alumnes via un QR que imprimiria el tutor. Respecte els internals es va començar a fer el framework rest, la impressió, QR, noves estructures de dades i avaluar tecnologies dev mobile per poder mantenir l'App (react native, PWA, ... ) L'App es feia al Cendrassos però els professors que ho preparàvem soms fora temporalment i no sé com està aquest tema.

En queslevol cas, m'apunto el suggeriment i el tinc molt en compte.

[amorilla]

Hola @ctrl-alt-d @juaky,

Suposo que no queda més remei que moure aquest tema. He pensat aquesta proposta per tenir usuaris separats a cada responsable d’alumne

Cal afegir un model Responsable amb les dades personals i de contacte. També es pot guardar la configuració de notificacions i que cada responsable pugui decidir la periodicitat.

El Responsable tindrà un usuari amb username respXXXX, podrà ser responsable de diversos Alumne i cada Alumne també podrà tenir diversos Responsable. Els responsables es diferenciaran pel seu DNI o NIE.

En fer la càrrega d’alumnes s’han de recollir les dades dels responsables: dni, adreça postal … Els camps d’Alumne amb dades dels responsables ja no faran falta. S’haurà de verificar si canvien els responsables de l’alumne, seran casos puntuals però pot passar.

En fer la Benvinguda s’enviaran emails als responsables i alumne.

Els responsables amb diversos alumnes, tindran una opció per escollir quin alumne volen gestionar.

El responsable principal (primer responsable) serà l’únic que podrà modificar paràmetres de l’alumne, en cas de tenir habilitada l’opció a les famílies.

S’han de comprovar tots els controls de verificació d’usuari per a permetre usuari professor, alumne o responsable i que no doni error.

La gestió de les dades dels responsables afecta a, com a mínim: alumnes extEsfera extSaga matricula relacioFamilies sortides tutoria usuaris

Altres aspectes: Per Alumne i Responsable es podria guardar el nom i email a User, com es fa amb el cas de Professor. En cas d’alumne major d’edat: Opció per decidir si deixa als responsables accedir? En cas de menor d’edat: Opció per decidir si el primer responsable deixa accedir a l’alumne?

Si aquesta idea sembla bé, creo una branch i vaig fent. I qui vulgui s'apunta i també pot fer.

[ctrl-alt-d]

Hola, gràcies.

• El responsable principal (primer responsable) serà l’únic que podrà modificar paràmetres de l’alumne, en cas de tenir habilitada l’opció a les famílies. Per què no tots dos? Sembla discriminatori. En matrimonis separats amb custodia compartida.

• Ara anotem quan el tutor llegeix les novetats del portal famílies. S'haurà de gestionar diferent.

Dani.

El dg., 20 d’oct. 2024, 19:08, Antonio Morillas @.***> va escriure:

Hola @ctrl-alt-d https://github.com/ctrl-alt-d @juaky https://github.com/juaky,

Suposo que no queda més remei que moure aquest tema. He pensat aquesta proposta per tenir usuaris separats a cada responsable d’alumne

Cal afegir un model Responsable amb les dades personals i de contacte. També es pot guardar la configuració de notificacions i que cada responsable pugui decidir la periodicitat.

El Responsable tindrà un usuari amb username respXXXX, podrà ser responsable de diversos Alumne i cada Alumne també podrà tenir diversos Responsable. Els responsables es diferenciaran pel seu DNI o NIE.

En fer la càrrega d’alumnes s’han de recollir les dades dels responsables: dni, adreça postal … Els camps d’Alumne amb dades dels responsables ja no faran falta. S’haurà de verificar si canvien els responsables de l’alumne, seran casos puntuals però pot passar.

En fer la Benvinguda s’enviaran emails als responsables i alumne.

Els responsables amb diversos alumnes, tindran una opció per escollir quin alumne volen gestionar.

El responsable principal (primer responsable) serà l’únic que podrà modificar paràmetres de l’alumne, en cas de tenir habilitada l’opció a les famílies.

S’han de comprovar tots els controls de verificació d’usuari per a permetre usuari professor, alumne o responsable i que no doni error.

La gestió de les dades dels responsables afecta a, com a mínim: alumnes extEsfera extSaga matricula relacioFamilies sortides tutoria usuaris

Altres aspectes: Per Alumne i Responsable es podria guardar el nom i email a User, com es fa amb el cas de Professor. En cas d’alumne major d’edat: Opció per decidir si deixa als responsables accedir? En cas de menor d’edat: Opció per decidir si el primer responsable deixa accedir a l’alumne?

Si aquesta idea sembla bé, creo una branch i vaig fent. I qui vulgui s'apunta i també pot fer.

— Reply to this email directly, view it on GitHub https://github.com/ctrl-alt-d/django-aula/issues/93#issuecomment-2425129014, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXWJP3E2O76CNF2THEXD63Z4PPRNAVCNFSM6AAAAABQIV7L7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRVGEZDSMBRGQ . You are receiving this because you were mentioned.Message ID: @.***>

[amorilla]

Hola,

M'ha semblat bona idea limitar els canvis als paràmetres per evitar una "guerra" de canvi de fotos, però, si no fa falta, millor. Es podrien marcar les notificacions com llegides si qualsevol dels dos responsables ho fa. L'important és que algú ho hagi fet. En cas de menors d'edat: Si un dels responsables ha llegit les notificacions, queden marcades com llegides. En cas de majors d'edat: Si l'alumne o un dels responsables ha llegit les notificacions, queden marcades com llegides.

Salutacions.

[ctrl-alt-d]

Si portem un control de 'quin tutor a llegit que' evitem del problema de 'a mi no m'ha arribat res'

[amorilla]

Doncs afegim els camps de notificacions al model Responsable: relacio_familia_darrera_notificacio periodicitat_faltes periodicitat_incidencies

[amorilla]

Hola @ctrl-alt-d @juaky He preparat una branch feature/usuariResponsable per implementar tot això. De moment ja permet fer servir usuaris respXXXX que tenen alumnes a càrrec. Adjunto uns fitxers d’importació per a fer proves: horaris-test.xml(treure el txt del final del nom) i saga-test.csv, contenen horaris de dos grups ASX2A i DAW2A, 3 professors prof1, prof2, prof3 i 8 alumnes per a cada grup. També crea 22 responsables, des de resp1 fins a resp22. Cada responsable té un altre amb el que fa la parella (1-2, 3-4, 5-6…, 21-22), des de l’1 al 16 tenen 2 alumnes, del 17 al 22 tenen un únic alumne.

Per facilitar les proves, en fer la càrrega de dades amb saga, crea els responsables i ja assigna una contrasenya. Cada responsable té com a contrasenya els seu username: resp1 resp1, resp2 resp2…

Hi ha una funció per obtenir el model adequat de l’usuari:

from aula.apps.usuaris.tools import getRol

Cada User pot correspondre a un Professor, Responsable o Alumne, amb getRol(user) s’obté el model corresponent. getRol(user) → retorna Professor, Responsable, Alumne Si es tracta d'un alumne retorna None, None, Alumne Si es tracta d'un responsable retorna None, Responsable, Alumne Si es tracta d'un professor retorna Professor, None, None Si no es tracta de cap cas retorna None, None, None

El Responsable pot canviar l’alumne a gestionar des del desplegable “Família de …” a la part superior dreta.

Si teniu temps, podeu escollir una app per adaptar-la. De moment jo començo per “matricula”.

Salutacions. saga-test.csv horaris-test.xml.txt

[ctrl-alt-d]

hola @amorilla,

gràcies per esperonar. He mirat una mica la branca que has creat. Tinc alguns comentaris i preguntes:

• A la issue ens afegeixes un saga-test.csv i horaris-test.xml per a fer proves. Però jo les proves sempre les feia executant el create_demo_data No puc fer proves amb aquest script per no haver de fer processos d'instal·lació?
• Veig que amb canviaAlumne tries sobre quin alumne vols veure dades. No posaries l'opció triada en sessió en comptes de posar-ho a la base de dades? Per defecte al protal podrien sortir els que tens i en tries un i, si només en tens un, doncs ja fem redirect a la pantalla de detalls d'aquell.
• Em fa una mica de por això de crear tots els responsables en carregar dades. Em mola molt això de tenir les dades controlades dels responsables (nom, cognoms, telèfon, localitat, etc) però tot són valors que es poden deixar en blanc. Ara és el tutor el que dona per bones les dades entrant els correus. Tinc la sensació que em perdo algo aquí. Crec que necessito ajuda.

Com ja havia comentat, crec que a cada tutor hauria de quedar-li clar les 'novetats' que té al portal. Ara es controla amb els camps relacio_familia_revisada i relacio_familia_notificada dels models:

• qualitativa: RespostaAvaluacioQualitativa
• sortida(es): NotificaSortida
• incidencies o observacions: Incidencia
• sanció(ns): Sancio
• expulsió(ns): Expulsio
• faltes assistència: ControlAssistencia

Llavors potser caldrien nous models (o un GenericForeignKey ) per portar el control de què ja ha vist i/o ha estat notificat a cada responsable. (Entenc que poden existir altres solucions com duplicar els camps posant un per cada responsable o coses semblants)

En tot cas és un bon avanç per eixugar un deute funcional important de l'aplicatiu.

[amorilla]

Hola @ctrl-alt-d,

No he modificat la generació de dades amb create_demo_data, però sí que s'hauria de fer servir per a preparar la base de dades. Per crear els usuaris Responsable era més fàcil fer la càrrega de l'horari i dels alumnes des dels fitxers de proves, ja que els usuaris responsables han d'estar relacionats per parelles i amb un o diversos alumnes. No fa falta fer cap procés d'instal·lació, es pot aprofitar una instal·lació ja feta. Per tant: 1-S'hauria d'executar el create_demo_data.sh (o simplement la part del fixtures). 2-Fer la càrrega de l'horari i dels alumnes dels fitxers de proves què he proporcionat. Això crea uns usuaris Responsable per a les proves. Com és un fitxer Untis, ja crea els grups. 3-Fer la reprogramació.

L'alumne que es gestiona es guarda a la sessió i a la base de dades. D'aquesta manera, al següent login, fa servir el mateix alumne de l'última vegada. Si només hi ha un alumne, aleshores no fa falta escollir cap. Ara selecciona el primer per defecte o l'últim que es va fer servir, però es podria mostrar una llista en fer login.

Els responsables són uns usuaris com qualsevol altre, podem decidir quines dades són obligatòries. Com a mínim dni, nom, cognoms, telèfon i email. Quan estigui tot acabat, els responsables es crearan en fer la càrrega d'alumnes. Els tutors podran veure les dades personals de l'alumne i dels seus responsables. En fer la Benvinguda, s'enviaran emails als responsables. Serà igual que ara, però amb 2 o 3 usuaris per alumne. En aquesta primera versió, per facilitar les proves, he modificat la importació de dades des del Saga per a crear uns usuaris responsables amb només el dni. És un canvi provisional, el funcionament real serà un altre, o potser no tindrem Saga, tinc entès que s'està fent la migració a Esfer@. En la versió definitiva, la càrrega de dades inclourà totes les dades personals i es crearan els usuaris per a cada alumne i responsables. El tutor enviarà les Benvingudes i els usuaris podran escollir la seva contrasenya.

Per a la gestió de les notificacions, tinc la següent proposta: Per a cada element a notificar s'hauria de guardar la data de creació de l'esdeveniment, no farà falta la data de notificació ni la de revisió. Amb l'historial de login podrem saber quan un usuari ha revisat cada cas. Tots els esdeveniments posteriors a l'últim login són els que encara no s'han revisat. Sí que farà falta afegir un historial de notificacions (del mateix estil que l'historial de logins) per saber quan s'ha fet la notificació a cada usuari. Cada element s'haurà notificat en la primera data de notificació posterior a la seva data de creació.

Salutacions.

[ctrl-alt-d]

Si les dades dels responsables les podem agafar de l'aplicatiu del dpt (Saga, Esfer@) llavors tot el que planteges em sembla una molt bona proposta. Potser l'únic que caldria seria una mena d'acceptació del responable que vol accedir a les dades o quelcom semblant i ja se li podria activar l'usuari i enviar la benvinguda. Crec que ara no agafem les dades dels responsables perquè no sempre estan bé. Ho puc consultar al centre de per què no ho estem fent.

No guardaria a la bd el darrer alumne revisat pel responsable, si n'hi ha més d'un que triïn quin és el que volen) Pot aparèixer el nombre de notificacions pendents al costat de cadascun.

Em sembla bé afegir una marca de temps als models per saber quan s'han creat i així saber si estan pendents o no de ser visualitzats pels responsables. També em sembla bé qualsevol estructura de dades que ens permeti saber si cal notificar/recordar novetat (nova incidència, sortida, etc) o ja ha estat notificada.

[amorilla]

Hola @ctrl-alt-d @juaky ,

Resum dels canvis: apps.matricula ja revisat, falten més proves generals quan estiguin els altres apartats.

apps.relacioFamilies Nou model Responsable delete(self): Marca com a baixa esBaixa(self): True si baixa force_delete(self): Esborra get_user_associat(self): retorna User get_alumnes_associats(self): retorna query d'Alumne

from aula.apps.relacioFamilies.tools import creaResponsables def creaResponsables(alumne, responsables, manteDades=False): Crea o modifica els responsables de l'alumne segons la llista responsables. responsables és una llista de diccionaris, cada diccionari conté els camps del responsable.

apps.alumnes Alumne get_responsables(self, rp1_dni=None, rp2_dni=None): Retorna els responsables de l'alumne, segons dni o els que siguin. esborraAltres_responsables(self, dnis): Esborra, de l'alumne, els responsables que no són a la llista dnis.

apps.presencia ControlAssistencia afegit camp "moment". get_relacio_familia_revisada(self, usuari, alumne): retorna última data de revisió que l'usuari-alumne ha fet d'aquest control get_relacio_familia_notificada(self, usuari, alumne): retorna data de notificació que l'usuari-alumne ha rebut d'aquest control A relacioFamilies.views.elMeuInforme ja es fan servir per a la gestió de notificacions i revisions. S'hauria de fer similar als altres models com: RespostaAvaluacioQualitativa, NotificaSortida, Incidencia, Sancio, Expulsio.

apps.usuaris Nou model NotifUsuari Guarda notificacions i revisions dels usuaris segons l'alumne que gestionen

from aula.apps.usuaris.tools import getRol, creaNotifAlumne, creaNotifUsuari, obteNotificacio, obteRevisio def getRol(usuari, request): Retorna Professor, Responsable, Alumne segons l'usuari. professor, responsable, alumne = getRol(user, request ) def creaNotifAlumne(alumne): Apunta notificació a l'alumne i als seus responsables. Segurament no es farà servir, ja que s'ha de tenir en compte que cada Responsable té la seva pròpia configuració de periodicitat. def creaNotifUsuari(usuari, alumne, tipus='N'): Apunta una notificació 'N' o revisió 'R' a l'usuari-alumne. def obteNotificacio(usuari, alumne, datahora): retorna la data-hora de la primera notificació posterior a datahora o None def obteRevisio(usuari, alumne, datahora): retorna la data-hora de la primera revisió posterior a datahora o None

Salutacions.