Wikini

PropositionsDEvolutionDeLActionUserSettings

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-18-204-214-205.compute-1.amazonaws.com

Propositions d'évolution de l'ActionUserSettings


Etude de la version actuelle

Fonctionnalités

La version actuelle de l'ActionUserSettings permet de :

Actuellement même si l'adresse de courriel est demandée, elle n'est pas utilisée dans WikiNi.

Table SQL

La table users est constituée des colonnes suivantes :

Décomposition de l'ActionUserSettings

L'ActionUserSettings est constituée par plusieurs formulaires HTML dont le fonctionnement est conditionné par la variable action (pseudo code) :


Proposition d'évolution de l'action

Discussion préliminaire

Pour la création des nouveaux utilisateurs, l'action doit pouvoir (paramétrable) :

Fonctions supplémentaires :

L'ajout de ces nouvelles fonctionnalités nécessiteront la modification de la table SQL users.

Mise en oeuvre

Variables de configuration

Ajout de deux variables de configuration :

Dans un premier temps, mettre ces variables dans $WakkaConfig et y accéder par une nouvelle méthode de l'objet wiki (voir InterfaceDAdministrationWikiNi discussion sur une nouvelle méthode appelée GetFunctionnalConfigValue - nom non définitif -). Tant que cette méthode n'existe pas utiliser GetConfigValue.

Discussion sur les méthodes de validation

Possibilités :

Ma préférence va pour la deuxième solution.

Il existe deja un systeme comparable sur Wiki5, un de WikiNi. --UnAnonyme

Discussion sur la fonction de création d'un nouveau mot de passe en cas de perte

Possibilités :



Décomposition de la nouvelle ActionUserSettings

En cours de jardinage ;o) (il faut encore y inclure la validation par l'utilisateur ou l'administrateur et la création d'un nouveau mot de passe)

Pseudo code :


Pour les options de configuration, il est préférable d'utiliser des constates (du genre DEFAULT_MODE etc.) entières (il suffit que chaque constante ait une valeur entière différente, et cette valeur pourrait même changer sans affecter tout le programme) Utiliser des chaines ne présente, à mon sens, aucun intérêt, au contraire même (fautes de frappe, plus d'utilisation de mémoire etc.)
Pour la clef de validation le mieux c'est d'utiliser uniqid()
Je pense qu'il va être inévitable d'avoir à créer plusieurs champs dans la table user
(il y a peut-être moyen de combiner ces champs, mais ça risque de compliquer tout...)
-- LordFarquaad

Nouvelle Table users


Pour activeuser, je trouve que ce n'est pas tout à fait clair, je préfèrerais quelque chose du genre user_is_active ou alors comme dans PhpBB2: user_active... On peut imiter aussi pour le reste: user_actkey et user_newpasswd. A la limite ça permet même de simplifier la fusion des deux (je pense qu'il y a des gens que cela intéresse...) [Pour ma part j'utilise active ENUM('Y','N','W'), 'W' correspondant à un compte en attente de validation (wait). -- ProgFou]
Ah oui sinon, pour le champ signuptime auquel personne n'a jamais trouvé d'utilité:
Comme son nom l'indique, j'imagine qu'il s'agit d'un compteur totalisant le temps passé à être connecté à WikiNi, c'est à dire la somme des durées de toutes les sessions. [Non, c'est plus simplement la date d'inscription de l'utilisateur. Cf actions/usersettings.php. -- ProgFou.] Seulement voilà, problème: WikiNi laisse la gestion des session se faire avec les fonctions existantes de PhP, c'est à dire via des fichiers temporaires auxquels il est difficile (impossible ? sinon c'est une faille potencielle en fait...) d'accéder. Il est donc impossible de savoir le temps que passent les utilisateurs à être connectés. Pour le faire il faudrait que ce soit géré via la base de données (notez que c'est très facile à mettre en oeuvre, et d'ailleurs je prévois de le faire pour pouver créer une action du style "WhoIsOnline") -- LordFarquaad

Est ce que dans le cadre des FeuillesDeStyleMultiples on ne devrait pas aussi rajouter une colonne indiquant quel style l'utilisateur veux utiliser (a choisir dans une liste de style disponible) ?? Cela grossi la table, mais évite le système de cookies et permet d'avoir le même style automatiquement malgré une utilisation multiposte... --BasHaq

Contrepoint
Pour ma part, je pense que s'il faut toucher à cette table c'est pour la dégraisser et non pour l'alourdir. Ca me rapelle l'histoire de petits CMS très sympa qui ont tellement grossis avec le temps qu'ils sont devenus des usines à gaz... Dans tout ce que vous proposez, beaucoup de champs ne seront utiles qu'à un utilisateurs sur 10 (ce qui est déjà un peu le cas). Je ne dis pas qu'ils n'ont pas d'intérêt, mais pourquoi ceux-là plutôt que d'autres ? Parce que des idées de métadonnées sur les utilisateurs je peux vous en fournir des wagons qui seront parfaitement défendables (il n'y a qu'à regarder les dizaines d'options que propose MediaWiki? (qui fait tourner wikipédia)) : timezone, barre d'édition, placement du menu, taille de la fenêtre d'édition, etc. Je ne vois aucune raison pour privilégier telles propriétés plutôt que d'autres. Les trois champs qui me paraissent utiles sont :
Seuls ces trois champs seront utiles à tous les utilisateurs. Le reste pourrait tenir, avec une requête SQL de plus, dans la table des triplets que je défend, permettant ainsi :
Qu'en pensez-vous ?
-- CharlesNepote
Je suis pour !
-- ErwanPigneul

J'en pense qu'il va falloir coder une action pour voter tout ça...
-- Nicephore17



Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]