- Jtimer-devel - mailman.cloud.codelutin.com

[ANN] - jTimer 1.5.3 released
by Eric Chatellier March 2, 2020

March 2, 2020

The jTimer team is pleased to announce the jtimer-1.5.3 release! jTimer - Project time tracking and report generation tool. Documentation of the project can be found here: https://gitlab.nuiton.org/chorem/jtimer Changes ------- Changes in this version include: #141: An illegal reflective access operation has occurred (java 10) #152: Use fatcow icon set #150: Does not build on JDK11 #149: Update libs #151: Error when displaying idle dialog NPE #144: Select the parent on "left arrow" key #148: An illegal reflective access operation on java 11 Downloads --------- For a manual installation, you can download files here: https://gitlab.nuiton.org/chorem/jtimer/releases * https://gitlab.nuiton.org/chorem/jtimer/uploads/7a124cdbc910ed5e236ddac2e27… Have fun! -jTimer team -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0

[ANN] - jTimer 1.5.2 released
by Eric Chatellier May 25, 2018

May 25, 2018

The jTimer team is pleased to announce the jtimer-1.5.2 release! jTimer - Project time tracking and report generation tool. Documentation of the project can be found here: https://gitlab.nuiton.org/chorem/jtimer Changes ------- Changes in this version include: New features: o Update libs o Fix project configuration and documentation Downloads --------- For a manual installation, you can download files here: https://gitlab.nuiton.org/chorem/jtimer/tags/ * https://gitlab.nuiton.org/chorem/jtimer/uploads/920a2cddd37e9a42af0a8cca683… Have fun! -jTimer team -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0

Synchronization to timebundle
by Eric Chatellier March 7, 2017

March 7, 2017

Hi, jTimer synchronization to timebundle is still in progress but can be tested in this version: https://forge.chorem.org/attachments/download/253/jtimer-1.5.2-534767e-time… (for developers, use branch : 'sync-timebundle') You will have to activate plugin using configuration described on following page: http://jtimer.chorem.org/v/develop/configuration.html Regards -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0

[ANN] - jTimer 1.5.1 released
by Eric Chatellier Jan. 13, 2017

Jan. 13, 2017

The jTimer team is pleased to announce the jtimer-1.5.1 release! jTimer - Time tracking tool. Documentation of the project can be found here: http://jtimer.chorem.org Changes ------- Changes in this version include: Fixed Bugs: o Bad webstart generation on snapshot site Issue: 1370. Thanks to Tony Chemit. Resolved by tchemit. o Revert modification to allow running multiple task at the same time Issue: 1359. Thanks to Éric Chatellier. Resolved by echatellier. o Application freeze after computer resume from hibernate Issue: 1366. Thanks to Éric Chatellier. Resolved by echatellier. Downloads --------- For a manual installation, you can download files here: https://forge.chorem.org/projects/jtimer/files * jtimer-1.5.1.zip - https://forge.chorem.org/attachments/download/250 Maven artifacts --------------- Artifacts are deployed in nuiton maven repository https://nexus.nuiton.org/nexus/content/repositories/other-releases/ Have fun! -jTimer team -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0

Timebundle plugin
by Eric Chatellier Aug. 3, 2016

Aug. 3, 2016

Hi, The sync code released on 1.6-alpha versions has been moved into a plugin disabled by default. The code is ok, but need further developpement to be released (coming soon). The develop branch is now back on 1.5.x version. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

2 2

jTimer 1.6-alpha-2 released
by Yannick Martel July 29, 2016

July 29, 2016

The jTimer team is pleased to announce the jtimer-1.6-alpha-2 release! jTimer - Time tracking tool. Documentation of the project can be found here: http://jtimer.chorem.org Changes ------- Changes in this version include: New features: o Be able to have subtask times when sync. a task Issue: 1364. Thanks to Yannick Martel. Resolved by servantie. Fixed Bugs: o Failures of synchronization (on startup and in some cases) Issue: 1365. Thanks to Charlène Servantie. Resolved by servantie. Downloads --------- For a manual installation, you can download files here: https://forge.chorem.org/projects/jtimer/files * jtimer-1.6-alpha-2.zip - https://forge.chorem.org/attachments/download/244 Maven artifacts --------------- Artifacts are deployed in nuiton maven repository https://nexus.nuiton.org/nexus/content/repositories/other-releases/ Have fun! -jTimer team -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28

1 0

[ANN] - jTimer 1.6-alpha-1 released
by Eric Chatellier July 25, 2016

July 25, 2016

The jTimer team is pleased to announce the jtimer-1.6-alpha-1 release! jTimer - Time tracking tool. Documentation of the project can be found here: http://jtimer.chorem.org Changes ------- Changes in this version include: New features: o Be able to send Task times on remote servers Issue: 1362. Thanks to Yannick Martel. Resolved by servantie. Fixed Bugs: o Empty time must not be add to file Issue: 1357. Thanks to Benjamin Poussin. Resolved by echatellier. o Application freeze after computer resume from hibernate Issue: 1345. Thanks to Éric Chatellier. Resolved by echatellier. Downloads --------- For a manual installation, you can download files here: https://forge.chorem.org/projects/jtimer/files * jtimer-1.6-alpha-1.zip - https://forge.chorem.org/attachments/download/241 Maven artifacts --------------- Artifacts are deployed in nuiton maven repository https://nexus.nuiton.org/nexus/content/repositories/other-releases/ Have fun! -jTimer team -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0

Re: [Jtimer-devel] [Jtimer-commits] 74/75: changed LocalDateTime type for last sync to Date, used YAML to save sync info
by Eric Chatellier July 11, 2016

July 11, 2016

Le 07/07/2016 17:48, chorem.org scm a écrit : > + Yaml yaml = new Yaml(); > + for (Object obj : yaml.loadAll(parseIn)) { > + if (obj instanceof SyncInfo) { > + task.addSyncInfo((SyncInfo) obj); > } Tu pourrais supprimer le 'instanceof', tu ne devrais pas avoir autre chose dans ce fichier. Limite c'est: List<SyncInfo> infos = (List<SyncInfo>)yaml.loadAll(parseIn); > +!!org.chorem.jtimer.entities.SyncInfo { > + isActiveSync: true, > + isWithAnnotations: false, > + lastSync: !!timestamp '1970-01-01T00:00:00Z', > + syncURL: 'http://localhost:3000' > +} C'est étrange comme forme de yaml, surtout le bloc avec {}. Tu pourrais aussi faire en sorte de ne surtout pas avoir le "org.chorem.jtimer.entities.SyncInfo" dans le fichier (ça empêche le refactoring). Et le "!!timestamp" qui ne semble pas très standard non plus. http://yaml.org/type/timestamp.html Merci.

1 0

Amélioration de la popup "reassignation du temps"
by Eric Chatellier May 26, 2016

May 26, 2016

Bonjour, La version 1.5 a été livrée il y a quelques temps maintenant, et certains d'entre vous on du tester la fonction permettant de reassigner le temps à une autre tâche. Cette popup : https://forge.chorem.org/attachments/download/238/idle.png Par contre, elle n'est pas aboutie, et pas ergonomique. Avez vous des recommandations pour améliorer cette popup ?

1 0

Re: [Jtimer-devel] [Jtimer-commits] 01/04: corrected method for getting times that was ignoring the date parameters and always sending all the times of a task
by Eric Chatellier May 23, 2016

May 23, 2016

Le 19/05/2016 09:23, chorem.org scm a écrit : > - String resultingJSON = "{\"uuid\":\"" + task.getName()+ > "\",\"periods\":" + getTimesAndCommentsJSON(task, startDate, endDate) > +"}"; > + String resultingJSON = "{\"URL\":\"" + > task.getSynchronisingURL()+ "\",\"periods\":" + > getTimesAndCommentsJSON(task, startDate, endDate) +"}"; Tu devrais te trouver une petite dépendance qui de permettrais de generer le json de facon plus efficace et maintenable. Genre "json-simple", "gson" ou ... plein d'autre : http://www.json.org/ Ensuite, deux cas soit tu as un objet convertible en Java, soit tu n'en a pas (comme ici). Cela donnerais un code genre: JSONObject response = new JSONObject(); response.put("URL", task.getSynchronisingURL()); response.put("periods", getTimesAndCommentsJSON(task, startDate, endDate)); return response.toString(); C'est un peu plus facile que les concaténations de chaîne.

2 1

Schema json
by Charlène Servantie May 4, 2016

May 4, 2016

Suite aux discussions de vendredi dernier, voici une deuxième version du schéma, avec pour changements principaux : la prise en compte d'un id pour les temps, et l'ajout d'une date de début et d'une date de fin pour définir l'intervalle de mise à jour, la date de fin étant optionnelle (si elle n'est pas présente, la mise à jour prend comme fin de période la date courante). Le terme de path a été changé en id pour pouvoir coller à différents modèles (dans le cas de jtimer il s'agit du path de la tâche, pour wid ça pourra être le tag).{ "description": "schema for the update of the times of a project/task", "$schema": "http://json-schema.org/draft-04/schema#", "definitions": { "task": { "type":"object", "properties": { "id": {"type": "string"}, "startDate" : {"type": "string"}, "endDate" : {"type": "string"}, "totalTime": {"type":"integer"}, "periods": { "type":"array", "items" : { "type" : "object", "properties": { "id": {"type":"string"}, "startDate":{"type" : "string"}, "duration": {"type":"integer"} } }, "minItems" : 1 }, "name": {"type": "string"}, "annotation": {"type": "string"}, "subtasks": { "type": "array", "items": {"$ref":"#/definitions/task"} } }, "required":["id", "startDate", "totalTime", "periods"] } }, "type":"object", "properties": { "task": {"$ref":"#/definitions/task"} } } avec un exemple : { "id":"path/le/chien", "startDate":"2002/02/02T00:00:00.000Z", "totalTime":300, "periods": [ {"id": "anAmazingID", "startDate":"2016/04/03T00:00:00.000Z", "duration":175}, {"id": "anOtheriD", "startDate": "2002/02/02T00:00:00.000Z", "duration": 78}, {"id": "IDitAgain", "startDate": "2006/10/20T00:00:00.000Z", "duration":58} ], "name":"6882", "annotation":"bla", "subtasks": [ ] }

3 2

Synchro jTimer
by Charlène Servantie April 25, 2016

April 25, 2016

Bonjour, nouvelle stagiaire inside, L'idée de mon stage étant d'étudier le besoin et de proposer une solution visant à synchroniser le temps saisi dans jTimer avec la gestion de projet dans chorem, voici les différentes idées/réflexions que j'ai noté par rapport à ce qui m'a été donné comme informations et ce que j'ai pu comprendre qui était demandé. A chaque tâche/projet, on pourrait associer une URL de synchro, qui pourra soit être configurée automatiquement lors de l'utilisation d'un template soit être ajoutée manuellement à la tâche/projet associé par l'utilisateur. Pour enregistrer la synchronisation d'une tache/projet, un fichier texte "nomfichier.extension.sync" contiendrait l'URL de synchronisation ainsi que la date de dernière synchronisation. On garde l'extension du fichier de tache/projet parce que sous jTimer les fichiers de tache sont en .task et les projets en .project. La synchronisation s'effectuerait par l'intermédiaire d'un envoi de fichier JSON. L'id de l'utilisateur envoyant ses temps serait transmis via un token dans l'URL. L'envoi d'une requête GET sur l'URL de synchronisation d'une tâche(/projet) si elle aboutit correctement renvoie la date de dernière synchronisation côté serveur (avec la réponse 200 - OK) permet ensuite de vérifier dans le fichier de synchronisation s'il s'agit de la même, sinon il y a alors envoi d'une requête POST avec un json des données de la tâche en question, suivi d'une mise à jour de la date de dernière synchronisation dans le fichier si tout se passe bien (ce qui permet l'édition à posteriori des temps sur les tâches aussi). (et renvoie des messages d'erreurs avec codes adaptés dans les cas contraires). J'ai réfléchi à un schema json qui permettrait de pouvoir vérifier la validité des données et avoir une définition de la structure à envoyer, les récepteurs pouvant ensuite choisir d'ignorer une partie des données à leur convenance. *Format JSON proposé : * on envoie la tâche avec son chemin, éventuellement son annotation, les dates associées aux temps passés sur cette tâche, le temps total pour cette tâche, et ses sous-tâches s'il y en a. Les dates seront au format YYYY-MM-DDTHH:MM:SS:sssZ (2012-04-23T18:25:43.511Z), le format renvoyé par JSON.stringify() en Javascript, et aussi conforme à la norme ISO 8601 et reconnu par notamment le w3c. Et surtout, facile à trier. Les temps seront sous la forme d'une clé selon la date et d'une valeur en secondes de temps, la date représentant la date de début pour la tâche (et les secondes la durée de travail sur la tâche). Pour les envois à partir de jTimer, la partie HH:MM:SS:sssZ sera systématiquement 00:00:00.000Z, puisque jTimer ne fait pas la distinction sur une même journée de plusieurs suivis d'une même tâche, mais que d'autres pourraient le faire (par exemple pour gérer les demi-journées).

2 3

[ANN] - jTimer 1.5 released
by Eric Chatellier March 30, 2016

March 30, 2016

The jTimer team is pleased to announce the jtimer-1.5 release! jTimer - Time tracking tool. Documentation of the project can be found here: http://jtimer.chorem.org Changes ------- Changes in this version include: New features: o Add report option to include intermediate total time Issue: 983. Thanks to Tony Chemit. Resolved by tchemit. o Can't delete multi selected tasks Issue: 1342. Thanks to Tony Chemit. Resolved by echatellier. o Stop all tasks button Issue: 780. Resolved by echatellier. o Enable "Enter" key support on main popups Issue: 1347. Thanks to Arnaud Thimel. Resolved by echatellier. o After creating a task, set the focus on this new task Issue: 1348. Thanks to Arnaud Thimel. Resolved by echatellier. o Add a way to create a tree structure from a template Issue: 1319. Thanks to Tony Chemit. Resolved by echatellier. o Option to only have one task running at a time Issue: 778. Resolved by echatellier. o Use log rotate to clean old backup Issue: 1330. Thanks to Éric Chatellier. Resolved by echatellier. o Remove dependency on jna-platform Issue: 1331. Thanks to Éric Chatellier. Resolved by echatellier. o When idle popup is displayed, show in the popup the current running taks(s) Issue: 1328. Thanks to Arnaud Thimel. Resolved by echatellier. o Add the ability to assign idle time to a task. Issue: 880. Resolved by echatellier. o Fix display tree angles lines in the main tree Issue: 1333. Thanks to Éric Chatellier. Resolved by echatellier. o Global icon to see that at least one task is running and would permit to stop all running tasks Issue: 84. Resolved by echatellier. Fixed Bugs: o Can't start with webstart Issue: 1338. Thanks to Tony Chemit. Resolved by tchemit. o I cancel the creation of a new task, but it is still created Issue: 1340. Thanks to Tony Chemit. Resolved by echatellier. o Double click on a running should stop it Issue: 1341. Thanks to Tony Chemit. Resolved by echatellier. o When creating a new task, focus is not ok Issue: 1337. Thanks to Tony Chemit. Resolved by echatellier. o Check the template directory exists (or create it at launch time ?) Issue: 1339. Thanks to Tony Chemit. Resolved by echatellier. o When éditing a task, please do not recompute the tree structure at the end Issue: 1343. Thanks to Tony Chemit. Resolved by echatellier. o Would like to specify save location Issue: 890. Resolved by echatellier. o Fix jTimer site URL in « about » Issue: 1188. Resolved by echatellier. o Big use of RAM Issue: 1004. Resolved by echatellier. o Task name can't accept */* character Issue: 1030. Thanks to Olivia Bruce. Resolved by echatellier. o If more than one task is running at a time, time is recorded in an accelerated manner Issue: 779. Resolved by echatellier. Changes: o Use Code Lutin signing certificate for jnlp application Issue: 981. Thanks to Tony Chemit. Resolved by tchemit. o Make webstart starts more friendly Issue: 956. Thanks to Tony Chemit. Resolved by tchemit. o Migrates to git Issue: 1128. Thanks to Tony Chemit. Resolved by tchemit. o Update libs Issue: 1320. Thanks to Éric Chatellier. Resolved by echatellier. o Remove xmlrpc web service layer Issue: 1323. Thanks to Éric Chatellier. Resolved by echatellier. o Use java 8 api Issue: 1322. Thanks to Éric Chatellier. Resolved by echatellier. o Add option to not display time in report Issue: 1329. Thanks to Éric Chatellier. Resolved by echatellier. Downloads --------- For a manual installation, you can download files here: https://forge.chorem.org/projects/jtimer/files * jtimer-1.5.zip - https://forge.chorem.org/attachments/download/240 Maven artifacts --------------- Artifacts are deployed in nuiton maven repository http://maven.nuiton.org/other-releases/ Have fun! -jTimer team -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0

Abandon de la compatibilité gTimer
by Eric Chatellier March 23, 2016

March 23, 2016

Bonjour, Pour clore proprement le ticket #1319, je préfererais abandonner la compatibilité gTimer et migrer le dossier .gtimer dans une nouvelle structure de répertoire .jtimer avec en sous dossiers: - data (actuel .gtimer) - backup - templates - ... Le format n'est déjà plus totalement compatible avec gTimer du fait des alertes #19 et gTimer n'est plus activement maintenu non plus. De plus, cela permettrait de faire evoluer un peu le format pour ajouter des informations, comme la description #988, par exemple. https://forge.chorem.org/issues/1319 https://forge.chorem.org/issues/19 https://forge.chorem.org/issues/988 -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 1

Etude des dépendances de jTimer 1.5.x
by Eric Chatellier March 7, 2016

March 7, 2016

Bonjour, jTimer étant toujours trop gros (> 7 Mo zippé) par rapport à ce qu'il fait, voici l'état des dépendances et des possibilités d'amélioration. Par taille de dépendance: - freemarker (1,4Mo) : utile pour les rapport, mais voir pour utiliser mustache à la place ? - swingx-core (1.2Mo) : librairie sous utilisées, mais quand même quelques composant difficile à remplacer - jna (1.1Mo) : pas possible de faire mieux à cause du code natif (so, dll) des plateformes cibles - log4j-core (1.1Mo) : c'est gros pour ce que c'est, voir pour un remplacant ? logback (450k) ? - commons-collection4 (600k) : dépendance de nuiton-config - commons-collection (600k) : dépendance de nuiton-config - commons-lang3 (450k) : on doit pouvoir s'en passer avec java 8, mais ... dépendance de nuiton-config - nuiton-utils : dépendance de nuiton-config - commons-beanutils: dépendance de nuiton-config - commons-io: pourrait ne pas être utilisée, mais fonctions bien pratique car la File API de java 7 a des manques - nuiton-config: utile pour ApplicationConfig - (et il en reste) -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

3 6

Java 8 Swing date picker
by Eric Chatellier March 7, 2016

March 7, 2016

Hi, Just to share : https://github.com/LGoodDatePicker/LGoodDatePicker It's a date picker using java.time.* API. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

2 1

Problèmes sur le site corrigés -- Project's site problems fixed
by Tony Chemit April 9, 2015

April 9, 2015

Hello, Il y avait plusieurs problèmes sur le site du projet (http://jtimer.chorem.org) Ils ont été corrigés :) Petit bonus : correction du jnlp pour utiliser un certificat reconnu. ~~~ Hi, We found some several problems on the project's site (http://jtimer.chorem.org) They have been fixed :). Extra bonus : we also fixed the jnlp usage of a correct certificate. Enjoy and Share. tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit(a)codelutin.com twitter: https://twitter.com/tchemit

1 0

Librairie pour faire des tous petits graphes
by Benjamin POUSSIN July 29, 2014

July 29, 2014

Salut, Voila une librairie pour faire de tous petits graphes, par exemple pour les temps des alarmes jtimer ou dans les rapports des barres graphes pour les temps par jours, ... http://omnipotent.net/jquery.sparkline/#s-about -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

1 1

Génération des rapport jour/semaine/mois/année
by Olivia Bruce June 27, 2014

June 27, 2014

Bonjour, Aujourd'hui je me trouve face à une petite difficulté au niveau de la génération de rapport. Qu'est ce que c'est? C'est le résumé de toutes les tâches et de tous les projets qui ont été minutés entre deux bornes (des dates : dateInf avec heure 00:00:00 et dateSup avec heure 23:59:59) définies par l'utilisateur. Pour retrouver les tâches minutées entre deux bornes, c'est assez facile, la base de données peut aisément calculer par projet la somme des temps et la renvoyer. Ensuite on traite les données pour reconstruire l'arbre, et afficher à l'utilisateur le rapport. Qu'est ce qui pose problème? Sur jTimer v1, il était possible de dissocier par jour/semaine/mois/années les tâches minutées; on souhaite donc rééditer cette fonctionnalité sous jTimer v2. Je souhaiterais pouvoir récupérer mes taches sous la contrainte des bornes avec en plus un groupement par période. Et je n'ai pas trouvé par exemple de façon de classer les taches minutées par semaine directement. 1. Peut être que je me trompe et que des moyens existent de grouper par jour/mois. /semaine/année comme en mysql, si c'est le cas avis au connaisseur pour m'éclairer. 2. Sinon, il faudrait récupérer toutes les données et les traiter ensuite en java pour replacer tous les temps/tâches dans leur période, puis ensuite reconstruire l'arbre pour chaque période. Ce qui peut vite devenir lourd avec un grand nombre de données. 3. Ou encore définir chaque petite période, puis faire appel à la base pour récupérer les tâches avec les temps pour chaque période, puis reconstruire l'arbre pour l'affichage. Mais bon ce n'est pas vraiment conseillé de faire plein de petits accès donc je déconseille. Si quelqu'un a une idée il serait intéressant de m'en faire part, Merci.

2 1

Re: [Jtimer-devel] [Jtimer-commits] r2995 - in branches/ng-jtimer/src/main: java/org/chorem/jtimer/entities java/org/chorem/jtimer/storage java/org/chorem/jtimer/web webapp/js
by Tony Chemit June 5, 2014

June 5, 2014

On Thu, 5 Jun 2014 18:19:13 +0200 (CEST) obruce(a)users.chorem.org wrote: > Added: branches/ng-jtimer/src/main/java/org/chorem/jtimer/entities/Pair.java On pourrait peut-être plutôt utiliser une classe qui existe déjà ? org.apache.commons.lang3.tuple.Pair > =================================================================== > --- branches/ng-jtimer/src/main/java/org/chorem/jtimer/entities/Pair.java (rev 0) > +++ branches/ng-jtimer/src/main/java/org/chorem/jtimer/entities/Pair.java 2014-06-05 16:19:13 UTC (rev 2995) > @@ -0,0 +1,46 @@ > +package org.chorem.jtimer.entities; > + > +import org.apache.commons.logging.Log; > +import org.apache.commons.logging.LogFactory; > + > +/** > + * Created by olivia on 05/06/14. > + * <p/> > + * Project name : jtimer > + * <p/> > + * Package name : org.chorem.jtimer.entities > + * > + * Cette classe represente un duo d'element type cle/valeur > + * @param <K> la cle > + * @param <V> la valeur > + */ > +public class Pair<K,V>{ > + > + protected static final Log log = LogFactory.getLog(Pair.class); > + > + private K key; //la clef de la pair > + private V value; //la valeur de la pair > + > + public Pair(K key, V value){ > + this.key = key; > + this.value = value; > + > + log.info(this.key.toString() + this.value.toString()); > + } > + > + public V getValue() { > + return value; > + } > + > + public void setValue(V value) { > + this.value = value; > + } > + > + public K getKey() { > + return key; > + } > + > + public void setKey(K key) { > + this.key = key; > + } > +} > -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit(a)codelutin.com twitter: https://twitter.com/tchemit

1 0

Proposition et question
by Olivia Bruce June 4, 2014

June 4, 2014

J'ai eu des propositions sur différents sujets que je préfère soumettre, dans ce qui suit je présente ce qui est en place et ce qui est proposé puis mon avis. Pour la synchro: Ce qui est présent : à chaque création d'un temps ou d'une tâche, on la pousse vers le serveur puis si une modification est faite on change l'élément en base. Si l'élément n'a pas pu être poussé il est stocké puis la tentative est faite plus tard. Avantage: pas de doublon, "petite" base Désavantage: perte des données de départ au profit des modifications Ce qui est proposé: avoir un système un peu comme des log qui va pousser un temps toutes les 5 min tant que le chrono est actif. pour les modifications il est alors ajouté un temps négatif. Avantage: tout est sauvegardé Inconvénient : volumétrie de la base, perte d'information sur le moment de la modification(début ou fin de période). Mon avis: Les deux solutions sont équivalentes, le risque de perte des données est faible. Cependant la seconde solution peut rapidement devenir trop volumineuse. Pour le fonctionnement de l'application: Ce qu'on a: L'UI est supposée fonctionner sans le module du serveur. L'UI stocke les données dans son local storage puis envoie les données vers le serveur qui stocke les données dans la base. Avantage: possibilité de fonctionner sans une connexion. Inconvénient: taille du local storage limité Proposition : Livré l'UI packagée avec un serveur pour permettre de se passer du local Storage et utiliser directement les données du serveur. Petit plus: utilisation des websockets pour prévenir l'UI. Avantage: pas de duplication des données (local Storage/base), Désaventage: plus lourd Mon avis: Je pense qu'il est probable que le localStorage ne puisse pas accueillir suffisamment de données. Il peut être intéressant d'utiliser la seconde idée.

2 1

algorithme de synchronisation
by Olivia Bruce May 20, 2014

May 20, 2014

Présentation simple de l'algorithme de synchronisation Ce qui est pris en compte: Ajout de tache/Modification de tache/Suppression de tache Ajout de periodde/Modification de periode/Suppression de periode La synchro se fait de l'UI vers le serveur et du serveur vers l'UI. La synchro se fait aussi du local storage vers l'UI et de l'UI vers le local storage. Il existe un systeme de todoList qui va gerer la synchronisation des elements de l'UI vers le serveur. Elle sauvegarde les taches et temps editees et les taches et temps crees/supprimees si la synchronisation n'a pas ete executee. Cette todoList est sauvegardee au cours du temps dans le local Storage de façon a ne pas perdre les modification sur les donnees si une synchro n'a pas pu se produire. L'Ui sauvegarde aussi son état dans le local Storage avec les webtimerdata. Synchro Ui -> Serveur Lors de l'ajout d'une tache dans l'UI, une demande d'ajout asynchrone est envoyée au serveur. Si la synchronisation échoue alors le nouvel élément est ajouté à la todolist. Lors de la suppression d'une tache dans l'UI, une demande asynchrone de suppression est envoyée au serveur. Si la synchronisation échoue alors l'élément supprimé est ajouté à la todolist. La modification d'une tache ou d'un temps ainsi que l'ajout ou la modification d'un temps ou la suppression d'un temps, est poussé dans la todoList, puis est traité de manière asynchrone. Sinon selon un intervalle (à définir - disons 10 min) une méthode se lance pour pousser de façon asynchrone les changements non traités (présents dans la todolist) vers le serveur. Synchro UI <- Serveur Au démarrage de jTimer une demande est faite automatiquement pour récupérer les tâches existante dans la base sous condition que la date de modification soit supérieur à la date de dernière synchro au serveur (sauvegardée dans la todolist et égale à 0 au premier démarrage pour récupérer toutes les dates). Les éléments récupérées sont ensuite comparé aux éléments du webtimerdata pour l'ajout ou la maj. Les temps sont récupérées pour chacune des sous-tâches avec toujours cette date de modification qui permet d'écrémer un peu le nombre d'élément rapatrié. A intervalle régulier les nouvelles taches sont rapatriées ainsi que les taches mise à jour. Jusqu’à maintenant on supprimait simplement les éléments de la base donc à la mise à jour suivante ils n'étaient pas récupérés. Ce système peut être à changer pour les synchro de plusieurs UI car sinon il devient difficile de repérer pour l'ui les tâches et périodes qui ont été supprimées de la base par un tiers sans parcourir toute la liste des tâches. Peut être avec une variable dans la base qui spécifie si l'élément a été supprimé.

1 0

Question sur JTimer v1
by Olivia Bruce April 23, 2014

April 23, 2014

Bonjour, Selon la discussion que l'on a eu dans le bureau, j'ai cru comprendre que la v1 avait été conçu de façon à ce qu'on ait qu'un temps par jour? Pourtant l'application permet l'émission de plusieurs temps pour une journée ou du moins la v2. Quels sont les raisons derrière ce choix? Il me semble pour moi important d'avoir plusieurs temps par jour pour une tâche, pour avoir un vraie suivie. Après je n'ai pas eu l'occasion de trop regarder le code de jTimer v1 donc peut être que je me trompe.

4 3

vision globale du projet
by Olivia Bruce April 22, 2014

April 22, 2014

- Au démarrage : Jtimer web tente de récupérer les éléments sur le serveur (findTasks(type de classement)) le serveur va demander à la base de donnée ou au serveur distant de lui fournir la liste des tâches selon un classement spécifié ( sans tache cachée, seulement les récentes... ) et va la fournir à l'UI. - A l'extinction : Les tâches dont le chrono n'est pas arrêté font la demande d'ajout de temps au serveur (addTime) et le serveur fait la demande à la base/serveur distant pour que le temps soit ajouté. Si une tâche doit être caché alors l'information est envoyé au serveur puis à la base - Création/ Ajout/ Suppression de tâche/ sous-tâche. Lorsque l'utilisateur souhaite : 1/ Créer une tâche/ sous-tâche : il clique sur l'élément permettant de créer des tâches qui ouvre un éditeur de champ et entre un nom, l'UI demande alors au serveur de créer la tâche (createTask) avec les infos spécifiées, la tâche est ensuite créée et stockée dans la base de donnée (dans le cas d'une sous-tâche le parent est spécifié). La base de donnée envoie ensuite une réponse success ou fail. 2/ Supprimer une tâche/sous-tâche : il clique sur l'élément qui supprime le tâche, si la tâche est une tâche feuille, on la supprime, on informe le serveur qui informe la base de donnée. si la tâche est un nœud (racine ou autre), l'ui s'assure que l'utilisateur est certain de son choix, si l'utilisateur est certain alors on demande au serveur de faire la suppression qui demande à la base la suppression récursive de ces éléments. -Activation/ Désactivation de tâche qui lance le compteur. 1/ Lorsque l'utilisateur active le chrono l'UI gère seule le chronométrage. 2/ Lorsque l'utilisateur désactive le chrono ou ferme le processus (stopTime) sans avoir désactivé un/plusieurs chrono alors l'UI demande d'ajouter ces informations (temps début,temps fin, tâche caché = false) au serveur qui demande d'enregistrer la date au début et en fin de chrono à la base de données. - Augmenter/Diminuer le temps passé sur une tâche. 1/ La tâche est en cours de chronométrage, l'UI le prend en compte. 2/ La tâche n'est pas en cours de chronométrage, l'UI envoie une demande de modification de temps (modifyTime) au serveur, il gère alors la demande à la base pour modifier la base de donnée (savoir quelle date modifiée, si il y a eu modification dans la journée ou pas) - Masquer/ Faire apparaître des tâches. 1/ Bouton au niveau de l'UI changement du statut de la tâche (la tâche passe sous un menu tâche caché ou visible). Lors de l'extinction de l'appli, l'information est envoyé au serveur pour que cette tâche ne soit plus affiché au prochain démarrage, la base est donc mise à jour. - Commenter une tâche. 1/ Bouton au niveau de l'UI changement de la note sur la tâche (un petit post-it peut être sur la tâche ). Demande serveur pour changer le commentaire sur la tâche, demande à la base. - Poser/ Enlever des alertes sur une tâche du type : -temps total à ne pas dépasser par tâche : clique droit ou clique sur symbole horloge de la tache projet côté UI demande au serveur d'ajouter une contrainte de temps ajout dans la base d'un temps limite pour la tâche. temps total à ne pas dépasser par jour sur une tâche : clic droit ou clique sur symbole horloge de la tache projet côté UI si temps respecté dans la journée alors pas de report reste dans l'UI sinon un popup demande si la contrainte doit être ajoutée pour la fois d'après si oui c'est enregistrer par le serveur dans la base. -Détection de l'inactivité (techno envisagée go). Gérer par l'UI, si inactif pas d'incrémentation du temps donc lorsqu'on ferme la fenêtre appel de addTime sans temps pas pris en compte. -Classement des taches : (tâches récentes ou par tag) Gérer par l'UI avec un menu défilant, l'affichage change en fonction de ce menu. Si affichage non typique type classement envoyée au serveur pour prochaine ouverture.

2 1

projet v2
by Olivia Bruce April 22, 2014

April 22, 2014

L'application avant : L'application Jtimer v1 permet à l'utilisateur de compter le temps passer sur un projet donner. Fonctionnalité : - Création/ Ajout/ Suppression de tâche/ sous-tâche. - Activation/ Désactivation de tâche qui lance le compteur. - Augmenter/Diminuer le temps passé sur une tâche. - Faire apparaître/ Masquer des tâches. - Commenter une tâche. - Poser/ Enlever des alertes sur une tâche du type : -temps total à ne pas dépasser par tâche. -temps total à ne pas dépasser par jour sur une tâche. - Détection de l'inactivité, arrêt si trop inactif. Ce que l'on veut pour la V2 : Fonctionnalité à reprendre de la V1 : - Création/ Ajout/ Suppression de tâche/ sous-tâche. - Activation/ Désactivation de tâche qui lance le compteur. - Augmenter/Diminuer le temps passé sur une tâche. - Faire apparaître/ Masquer des tâches. - Commenter une tâche. - Poser/ Enlever des alertes sur une tâche du type : -temps total à ne pas dépasser par tâche. -temps total à ne pas dépasser par jour sur une tâche. - Détection de l'inactivité (techno envisagée go). Fonctionnalité de la V2 : - Solution avec un serveur local pour synchroniser les données et permettre un interface avec des applis tiers. - Lancement sur un serveur local : jetty pour l'instant - UI gérée par Angularjs, rafraîchissement en temps réel. - Interaction ui-server - Enregistrer en local les données dans une base de données h2 : 2 tables pour l'instant task et tasktime. ? Utilité de la mise en cache des tâches actuelles dans le navigateur ? Peut être pour le test. - Récupération des données pour synchronisation de l'interface au démarrage : requête REST - Centralisation des données pour avoir une vision globale des temps passés, par la suite gestion avec Chorem. - Technos envisagées : Java/AngularJS/Go/Maven/H2/Jetty Ce que veulent les utilisateurs : - Possibilité d'avoir des tâches personnelles qui ne se synchronisent pas avec le reste. - Pouvoir dé-commenter des tâches. - Archivage (pas d'apparition) des tâches terminées. - Système de taches urgentes. Idée d'ajout : - Ajouter un label/service à la tâche pour pouvoir faire des statistiques sur un label/service - Lancement de l'alerte avant fin de temps → avoir une barre de chargement statique ou dynamique (ui.bootstrap.progressbar) http://angular-ui.github.io/bootstrap/ Ou encore Stacked pour le projet général permettrait de faire un truc sympa au niveau du temps total ( diagramme de Gant style). A faire : - Gestion de la base de données - Mise en place de communication REST entre l'UI et le serveur local - Définir le process de synchronisation - Étudier comment permettre l'ajout de nouvelles sources de synchronisation (ex: chorem, redmine, un autre serveur local).

2 1