Les utilisateurs ayant un rôle avec un accès en lecture seule sur l'agenda, peuvent créer un nouvel évènement dans l'agenda de leur groupe.

J'ai des RDV répétitifs tous les lundi a 10h00.

J'ai souhaité les modifier pour les mettre le mardi a 14h30, en changeant la prochaine échéance et en sélectionnant l'option "Action sur tous les RDV de la série à partir de ce jour".

TT a bien modifié le échéances à venir pour le nouveau jour aux nouveaux horaires par contre il a :

- Conserver au lundi avec les anciens horaires l'échéance sur laquelle j'ai fait les modifications
- créer une nouvelle échéance le mardi suivant l'échéance sur laquelle j'ai fait les modifications

En regardant dans mySQL admin, j'ai constaté que les enregistrements initiaux ont été supprimé et remplacé par de nouveaux enregistrements sauf celui que lequel les modifications sont faites

Dans les working database, TT rajoute un anti-slash a chaque nouvelle modification d'un enregistrement contenant un guillemet.

Il suffit de supprimer le addslashes() ligne 179 du fichier wbd_gestion_action.php, cela ne semble pas posé probleme.

Lors de la saisie d'un événement dans l'agenda avec les mêmes informations d'horaire (ex : 0845 - 0845) TT ne crée pas l'événement et n'affiche pas de message. On a l'impression que tout c'est bien passé.

faut-il faire le controle en JavaScript ou en PHP ?

Le code de Toutateam devrait être nettoyé des appels à la fonction error_reporting() de PHP. Ceux-ci empêchent un deboguage efficace de l'application en cas de problème. Le niveau de verbosité des messages de PHP devrait être géré par l'administrateur dans la configuration d'Apache/PHP, au sein d'un virtual host ou globalement, mais certainement pas dans le code lui-même.

J'ai constaté que lors de l'affichage de l'écran de login le titre ne s'affiche pas

Sur la demo "Toutateam - Login" s'affiche mais rien dans la version SVN

Il semble que ce soit le test "if(!headers_sent())" a la ligne 19 du fichier authform.inc.php qui empeche cet affichage

Si on supprime le test il y a 2 sections HEAD dans la page

Lors de la connexion avec le skin "default" TT affiche en haut à gauche un certain nombre d'informations dans un carré rose.

Sur mon DEV j'ai créé un skin (ndc) dans lequel on peut gérer l'affichage du startstring pour le passer de 1 à 3 lignes de façon a économiser de l'espace dans la fenetre

=> pour l'instant j'utilise le champ postal comme paramétre (si 1234) pour déterminer le nombre de ligne à afficher
=> il faut envisager une table de gestion des paramètres utilisateur

J'ai ajouté un lien pour sortir => si on a beaucoup de module il faut utiliser les flèches de navigation

Dans les écrans du module mail certains boutons sont des liens HREF, affichant la main de la souris en cas de onMouseOver et d'autres sont des boutons qui n'ont aucun comportement en cas de onMouseOver

De façon a harmoniser j'ai modifié, sur mon DEV, les boutons "supprimer, imprimer et retour" du masque "création de repertoire" et "affichage d'un mail recu".

A mon sens il faudrait revoir tous les boutons pour qu'ils aient tous le même comportement

J'ai aussi modifié le bouton "Retour" afin qu'il récupère le HTTP_REFERER et qu'il revienne dans le dossier précédent et non le dossier par défaut :

=> Dans TT si on est positionné dans le dossier "4" et qu'on visualise un mail de ce dossier lors de l'utilisation du bouton "Retour" on revient dans la "Boite de réception"
=> Dans mon DEV i on est positionné dans le dossier "" et qu'on visualise un mail de ce dossier lors de l'utilisation du bouton "Retour" on revient dans le dossier "4"

Lors d'une erreur de saisie du couple Login / Mot de passe TT affiche une ligne d'informations et un lien de retour vers l'écran de saisie.

Sur mon serveur de DEV j'ai modifié les fichiers auth.inc.php - authform.inc.php pour réafficher l'ecran de saisie affichant le message d'erreur en rouge au dessus du champ Login

=> Simplification de la procédure pour des utilisateurs intensif qui doivent retaper souvent le mot de passe

Afin de gérer l'affichage des informations en fonction de la résolution de l'ecran du client => si sur un portable en 1024x768 ou sur un 21' en 1280x1024 on ne peut pas afficher le même nombre d'informations

Pour cela je demandes, en javascript, au navigateur de reloader la page avec des paramètres dans l'URL puis j'enregistre les screen.height et screen.width dans 2 variables a l'aide de reg_sess_var

Cela me permet de gérer des paramétres d'affichage dans un templates perso (ndc) mais serait applicable pour tout l'environnement