Permet escollir límit de logins erronis

[amorilla]

A vegades els usuaris fallen en posar la contrasenya, per oblit, per fer servir un equip diferent de l'habitual que ja té guardada una contrasenya antiga, per confusió en l'username. Actualment el límit és de 3 intents, si se supera el límit, es bloqueja l'usuari. Per a poder augmentar la quantitat límit, s'ha afegit un paràmetre als settings LIMITLOGIN=3.

Més canvis: S'ha modificat la manera d'impedir que un usuari de direcció pugui fer impersonació com a administrador. Ara mostra un missatge informatiu.

[amorilla]

Hola, He afegit LIMITLOGIN als settings. El valor dels settings és el de defecte. Per augmentar-lo es pot fer des de paràmetres d'admin/extkronowin/paràmetres Kronowin. D'aquesta manera es pot posar un valor més gran a l'inici de curs, que acostuma a acumular molts casos de confusió, i posteriorment deixar-lo en una quantitat més segura.

[ctrl-alt-d]

No acabo de pillar perquè ho posem a l'App ExKronowin . Aquesta App seria només per a coses relacionades amb Kronowin i això sembla un paràmetre general. No ho podríem deixar només als settings? Què aporta posar-ho a ExKronowin? (tocar el setting i reload de djau és un moment, no veig el punt de posar-ho a la bd) Potser em perdo alguna cosa.

[amorilla]

Hola,

L'objectiu és aconseguir una manera ràpida i còmode de modificar la quantitat de logins erronis abans de bloquejar usuari. A principi de curs es pot fer servir una quantitat i posteriorment una altra. Els paràmetres de la base de dades són una manera ideal, no fa falta accedir al servidor a executar comandes. A on han d'anar aquests paràmetres? Aquest és el punt complicat què s'hauria de replantejar. Alguns paràmetres de extsaga i extesfera podrien ser comuns. En el cas de extkronowin i extuntis tenen paràmetres comuns (extuntis els agafa de extkronowin). A Kronowin tenim la contrasenya per defecte d'usuari professor, potser també hauria de ser un paràmetre general i no exclusiu de kronowin. Per tant, com a extKronowin hi ha la contrasenya d'usuari, m'ha semblat que també es podia posar aquest nou paràmetre de limitLogin. Potser el més adequat seria una taula única de tots els paràmetres per a qui els necessiti.

Si es creu més adequat, elimino el paràmetre i deixo només el settings.

Salutacions.

[ctrl-alt-d]

A Kronowin tenim la contrasenya per defecte d'usuari professor, potser també hauria de ser un paràmetre general

És perquè els professors els crea ExtKronowin. Ho vaig posar a la bd per si des de direcció ho volien anar canviant de tant en tant.

Potser el més adequat seria una taula única de tots els paràmetres per a qui els necessiti.

M'agrada, sempre que es pugui, deixar els paràmetres als settings com a lloc central de parametritzar. Sí que és veritat que hi ha paràmetres a la bd i podríem fer aquesta taula de settings generals si cal.

Si es creu més adequat, elimino el paràmetre i deixo només el settings.

Per mi és millor en un sol lloc i si pot ser als settings. Jo voto sí a deixar-ho només als settings. Però si ho veieu millor a la bd també em sembla bé tal com planteges. A veure què opina en @juaky . Sorry @amorilla per tots els comentaris, trobo que fas molt bona feina i no vull posar traves de cap mena ni desanimar.

[juaky]

Hola nois. Jo, potser perquè estic acostumat a fer -ho així, opto per tenir -ho al settings. De fet ja vaig fer la proposta fa uns dies: https://github.com/ctrl-alt-d/django-aula/pull/209#pullrequestreview-1169660177

[amorilla]

Deixo només el paràmetre dels settings.

[rafatecno1]

Potser el més adequat seria una taula única de tots els paràmetres per a qui els necessiti.

M'agrada, sempre que es pugui, deixar els paràmetres als settings com a lloc central de parametritzar. Sí que és veritat que hi ha paràmetres a la bd i podríem fer aquesta taula de settings generals si cal.

Personalment crec que tenir un lloc amigable per adaptar els settings faria que el DjAu fos molt més fàcil de gestionar. Vosaltres teniu al cap tots els paràmetres del programa, la resta no. En aquest sentit crec que el DjAu por avançar molt. Que quedi clar, no ho dic per donar-vos feina. Ara que he estic amb la programació del djau i que estic acabant l'app que estic fent, em veig capaç d'aportar-hi coses, tot i que, com deia, ni tinc ni puc tenir tot el projecte al cap.

En el meu món ideal veig una entrada a l'administrador, o mes d'una, amb els paràmetres locals, convenientment explicats, si calgués. També serien fàcils d'exportar i importar entre diferents instal·lacions.

Evidentment implica una taula expressa per paràmetres locals i afegir una mica de complexitat al codi, poca en realitat, però guanya en usabilitat de l'administrador, al que se li ha de posar la vida fácil. Sóc dels que pensa que l'administrador ha de treballar el menys possible amb la terminal. N'hi ha que no havien fet anar mai Linux abans (ehem, ehem...)

[ctrl-alt-d]

@rafatecno1 , @amorilla , @juaky , Comparteixo aquí la meva visió de la parametrització. Ho comparteixo perquè potser algú té alguna idea més bona del que exposo i podem fer millor les coses i podem millorar el sistema. Sisplau, si algú té propostes concretes endavant!! Merci!

Els settings estan (o haurien d'estar) tots centralitzats i documentats aquí:

https://github.com/ctrl-alt-d/django-aula/blob/master/aula/settings.py

Qualsevol setting es pot sobre escriure al setting_local.py.

Per norma general, quan es creen mòduls / funcionalitats que alteren el programa, es crea un setting que permet deixar el comportament vell, si es vol el nou, se sobreescriu el setting. Dic per norma general perquè hi ha funcionalitats guapes que tothom vol i que no els cal el setting.

Havíem tingut documentats els paràmetres (https://github.com/ctrl-alt-d/django-aula/blob/master/docs/manuals/parametritzacions.txt ) però va quedar desactualitzat. No costaria gaire documentar cada paràmetre al mateix fitxer de settings. Crec que el fitxer de documentació no cal.

@rafatecno1 diu: En el meu món ideal veig una entrada a l'administrador, o mes d'una, amb els paràmetres locals, convenientment explicats, si calgués.

Veig inconvenients de posar paràmetres a la bd:

• En crear nous paràmetres hauràs de modificar les migrations per afegir-los.
• Al fitxer de settings es veuen tots i es poden documentar, a la bd, fins que no tinguis l'app engegada no els veuràs.
• Hi ha paràmetres complexes (llistes, diccionaris, ....), a la bd els hauries de tenir serialitzats en un json, al fitxer de settings és simplement python. A la bd ningú et validarà la sintaxi i poden fer que l'aplicació falli en temps d'execució deserialitzant el paràmetre.

Veig necessitat de posar paràmetres a la bd si els ha de poder canviar direcció

@rafatecno1 diu: També serien fàcils d'exportar i importar entre diferents instal·lacions.

Veig més fàcil copiar el fitxer settings_local.py d'un any per l'altre que no pas haver d'exportar i importar una taula (i preservar tots els nous settings que puguin haver aparegut a l'estiu). Potser m'estic perdent alguna cosa.

salut!