Author: jcouteau Date: 2011-03-04 14:30:30 +0100 (Fri, 04 Mar 2011) New Revision: 743 Url: http://nuiton.org/repositories/revision/wikitty/743 Log: Improve doc : - Improve security part - add model examples in generation part - add spec page in generated site - fix spelling mistakes Added: trunk/src/site/resources/user/ trunk/src/site/resources/user/wikittyDependency.png trunk/src/site/resources/user/wikittyTree.png trunk/src/site/rst/user/generation.rst.vm Removed: trunk/src/site/rst/user/generation.rst Modified: trunk/src/site/rst/Spec.rst trunk/src/site/rst/user/security.rst trunk/src/site/site_fr.xml Added: trunk/src/site/resources/user/wikittyDependency.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/user/wikittyDependency.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: trunk/src/site/resources/user/wikittyTree.png =================================================================== (Binary files differ) Property changes on: trunk/src/site/resources/user/wikittyTree.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Modified: trunk/src/site/rst/Spec.rst =================================================================== --- trunk/src/site/rst/Spec.rst 2011-03-04 10:55:53 UTC (rev 742) +++ trunk/src/site/rst/Spec.rst 2011-03-04 13:30:30 UTC (rev 743) @@ -29,8 +29,8 @@ ========================= Les identifiants sont de la forme UUID[_<specifique extension>]. Donc tous les -identifiants commence par un UUID et peut être séparé d'une extension -spécifique pour certain besoin par un '_' (underscore). +identifiants commencent par un UUID et peuvent être séparé d'une extension +spécifique pour certains besoins par un '_' (underscore). C'est le mécanisme de base de génération des wikitty-id. Il y a toutefois des exceptions : @@ -44,21 +44,21 @@ WikittyServiceNotifier ====================== -Tous les events passant par le WikittyServiceNotifier sont envoyé au -RemoteNotifier s'il est indiqué dans la configuration qu'il faut envoyer les -events (wikitty.service.event.propagateEvent). Il faut alors dans ce cas +Tous les évènements passant par le WikittyServiceNotifier sont envoyé au +RemoteNotifier s'il est indiqué, dans la configuratio,n qu'il faut propager les +évènements (wikitty.service.event.propagateEvent). Il faut alors dans ce cas définir le transporter à utiliser (wikitty.notifier.transporter.class). -Le transporter sert à envoyer(serveur) et recevoir(client) les events. Le +Le transporter sert à envoyer(serveur) et recevoir(client) les évènements. Le même transporter doit être utilisé pour le client et le serveur. -Il existe aujourd'hui deux types de transporter différent (jgroups, xmpp). +Il existe aujourd'hui deux types de transporter différents (jgroups, xmpp). L'implantation jgroups pose quelque soucis (ne fonctionne pas toujours). Il est donc préférable d'utiliser le transporter xmpp. -Il est bien sur possible d'empiler deux couche de WikittyServiceNotifier -avec des transporters différents coté serveur pour permettre à différent -type de client de fonctionner en même temps (FIXME poussin 20101115 il n'est +Il est bien sûr possible d'empiler deux couches de WikittyServiceNotifier +avec des transporters différents coté serveur pour permettre à différents +types de client de fonctionner en même temps (FIXME poussin 20101115 il n'est pas actuellement possible de configurer ce fonctionnement) Pour utiliser le transporter xmpp il faut que vous ayez un serveur xmpp avec @@ -120,109 +120,6 @@ notifications qu'on a pas pu lui envoyer et on lui renvera tout ce qu'il a manqué lorsqu'il sera de retour. (utile pour la synchro serveur) -Gestion des droits -================== - -Utilisateurs et groupes ------------------------ - -Les utilisateurs ont un nom et un mot de passe, les groupes contiennent -des utilisateurs et d'autres groupes - -Par défaut il existe un *WikittyGroup* portant le nom **WikittyAppAdmin**. -Si ce groupe n'existe pas ou qu'il est vide, cela indique que tous les -utilisateurs sont AppAdmin. Cela est nécessaire pour deux choses: - -- pour permettre d'avoir une authentification, mais que l'on ne souhaite pas de - gestion d'autorisation. - -- pour servir de bootstrap au lancement de l'application seul les AppAdmin - peuvent modifier le *WikittyGroup* portant le nom **WikittyAppAdmin**, or s'il - est vide il faut pouvoir le remplir. - -Il ne doit donc exister un seul *WikittyGroup* portant le nom -**WikittyAppAdmin** - -Tokens de sécurité ------------------- - -À chaque login, un token de sécurité est fourni à l'utilisateur. L'utilisateur -doit fournir ce token à chaque opération pour montrer qu'il a les droits. -Pour un token donné, on peut savoir à quel utilisateur il appartient. - -Les tokens sont stockés en base et supprimés au logout de l'utilateur. - -Les SecurityToken ne sont supprimés de la base de données qu'au moment du logout -Si les utilisateurs/applications quittent sans faire le logout le nombre de -SecurityToken ne fera qu'augmenter. Pour éviter cela, il faut prévoir un petit -job qui de temps en temps fait le ménage dans les SecurityToken trop vieux. - -Gestion des droits sur un Wikitty (sécurité niveau 1) ------------------------------------------------------ - -Un wikitty a plusieurs extensions, pour chacune de ces extensions, on a plusieurs -droits. On distinque quatre niveaux de droits : - -* owner (un utilisateur) donne tous les droits sur un wikitty - -* admin (zéro ou plusieurs utilisateurs / groupes) permet d'ajouter ou de - supprimer des éléments dans writer et reader, et tous les droits comme 'owner' - -* writer (zéro ou plusieurs utilisateurs / groupes) permet, pour chacun des - champs de cette extension, de modifier la valeur - -* reader (zéro ou plusieurs utilisateurs / groupes) permet, pour chacun des - champs de cette extension, de lire la valeur - -Si on veut que tout le monde puisse lire un wikitty, il faut laisser vide la -liste des readers (vide ou null). - -Si l'on souhaite indiquer que personne ne peut lire l'objet il faut mettre le -owner en tant que reader. Car de toute façon l'owner aura toujours le droit -en lecture. - -La granularité des droits se situe donc au niveau de chaque instance. On doit -pouvoir définir le droit pour chaque extension, de chaque wikitty. Il n'y a -pas de gestion des droits par champs. Avoir le droit *reader* sur une extension -d'un wikitty donne le droit de lecture sur tous les champs de cette extension. - -Du point de vue structure de données, ces droits sont stockés sur le wikitty -lui-même, dans des champs spécifiques. Par exemple, si le wikitty porte -l'extension *Ext*, il portera également l'extension « Ext:WikittySecurity » -et il y aura, sur le Wikitty, un champ nommé « owner » (dont le FQN est -« Ext:WikittySecurity.owner »). - -Autre exemple, si un wikitty porte 3 extensions, ayant chacune 10 champs. -Le wikitty aura, au total, 42 champs : 3 × 10 champs + 3 extensions × 4 champs -(les 4 champs de l'extension WikittySecurity). - -Gestion des droits sur les extensions (sécurité niveau 2) ---------------------------------------------------------- - -Pour chaque extension, on a la même hiérachie de droit qui donnent des -possibilités différentes : - -* owner : - -* admin : permet de changer les droits de l'extension. Donc, permet d'ajouter - ou de supprimer des éléments dans writer et reader - -* writer : permet de modifier l'extension - -* reader : permet de lire l'extension pour en créer des instances. Si le reader - est vide, tout le monde peut créer. Pour que seuls les AppAdmin et le owner - puissent créer des instances, il faut mettre le owner en reader. - -Si une extension ne dispose pas de ces informations, seuls les AppAdmin peuvent -créer les instances et modifier l'extension. - -Ces droits sont stockés sous le forme d'un Wikitty. Pour chaque extension -connue, il y aura donc un wikitty dont la seule extension sera WikittySecurity. - -Chacun de ces wikitty aura pour identifiant « WikittySecurity:ExtensionName ». -permet de court-cuircuiter la recherche solR, et un passage par le réseau à -chaque store/restore. - Localisation ============ Deleted: trunk/src/site/rst/user/generation.rst =================================================================== --- trunk/src/site/rst/user/generation.rst 2011-03-04 10:55:53 UTC (rev 742) +++ trunk/src/site/rst/user/generation.rst 2011-03-04 13:30:30 UTC (rev 743) @@ -1,111 +0,0 @@ -.. - -.. * #%L -.. * Wikitty -.. * -.. * $Id$ -.. * $HeadURL$ -.. * %% -.. * Copyright (C) 2009 - 2010 CodeLutin -.. * %% -.. * This program is free software: you can redistribute it and/or modify -.. * it under the terms of the GNU Lesser General Public License as -.. * published by the Free Software Foundation, either version 3 of the -.. * License, or (at your option) any later version. -.. * -.. * This program is distributed in the hope that it will be useful, -.. * but WITHOUT ANY WARRANTY; without even the implied warranty of -.. * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -.. * GNU General Lesser Public License for more details. -.. * -.. * You should have received a copy of the GNU General Lesser Public -.. * License along with this program. If not, see -.. * <http://www.gnu.org/licenses/lgpl-3.0.html>. -.. * #L% -.. - -====================================== -Générer son modèle métier vers Wikitty -====================================== - -Modélisation -============ - -Vous pouvez modéliser votre modèle métier en utilisant n'importe quel modéliseur -UML pouvant enregistrer le modèle au format xmi (ArgoUML, Topcased,...). Les -entités que vous souhaiter générer doivent avoir le stéréotype *entity*. - -Configuration Maven -=================== - -Pour générer le code, nous utilisons EUGene_ et son plugin Maven. - -Dans le pom de votre projet, rajoutez la définition du plugin:: - - <plugin> - <groupId>org.nuiton.eugene</groupId> - <artifactId>maven-eugene-plugin</artifactId> - <version>2.2/version> - <executions> - <execution> - <id>api generator</id> - <phase>process-sources</phase> - <configuration> - <inputs> - <input>zargo:src/main/xmi/:*.zargo</input> - <input>classpath:model:/:wikitty.objectmodel - </input> - </inputs> - <fullPackagePath>your.app.package</fullPackagePath> - <defaultPackage>your.app.package</defaultPackage> - <extractedPackages> - your.app.package,org.nuiton.wikitty - </extractedPackages> - <generatedPackages>your.app.package</generatedPackages> - <templates> - org.nuiton.wikitty.generator.WikittyMetaGenerator, - org.nuiton.wikitty.generator.WikittyDTOGenerator - </templates> - </configuration> - <goals> - <goal>smart-generate</goal> - </goals> - </execution> - </executions> - </plugin> - -Dans la section *inputs*, on spécifie le(s) modèle(s) métier:: - - zargo:src/main/xmi/:*.zargo - -ainsi que le modèle Wikitty (en cas de dépendance de votre modèle métier vers le -modèle Wikitty). - -Dans la section *templates*, vous pouvez spécifier quoi générer : -*org.nuiton.wikitty.generator.WikittyMetaGenerator* pour la génération Wikitty -standard et *org.nuiton.wikitty.generator.WikittyDTOGenerator* pour la -génération des DTOs si besoin. - -Génération -========== - -La génération est effectuée ensuite à chaque fois que vous lancez un build. - -Subtilités de modélisation -========================== - -Dépendances vers l'API de Wikitty ---------------------------------- - -Il est possible de rajouter une dépendance vers un objet de l'API Wikitty (par -example WikittyUser) en rajoutant simplement la classe dans votre modèle dans le -package* org.nuiton.wikitty.api*. Elle ne sera pas générée mais interviendra -comme une autre classe de votre modèle (héritage,...). - -Arbres ------- - -Si vous souhaitez qu'une entité crée un arbre, vous avez juste à faire hériter -cette entité de WikittyTreeNode (pas besoin de référence sur elle-même). De -cette manière, la gestion de l'arbre est assurée par Wikity, de même que -l'indexation et la recherche. - -.. _EUGene::http://maven-site.nuiton.org/eugene/ \ No newline at end of file Copied: trunk/src/site/rst/user/generation.rst.vm (from rev 738, trunk/src/site/rst/user/generation.rst) =================================================================== --- trunk/src/site/rst/user/generation.rst.vm (rev 0) +++ trunk/src/site/rst/user/generation.rst.vm 2011-03-04 13:30:30 UTC (rev 743) @@ -0,0 +1,115 @@ +.. - +.. * #%L +.. * Wikitty +.. * +.. * $Id$ +.. * $HeadURL$ +.. * %% +.. * Copyright (C) 2009 - 2010 CodeLutin +.. * %% +.. * This program is free software: you can redistribute it and/or modify +.. * it under the terms of the GNU Lesser General Public License as +.. * published by the Free Software Foundation, either version 3 of the +.. * License, or (at your option) any later version. +.. * +.. * This program is distributed in the hope that it will be useful, +.. * but WITHOUT ANY WARRANTY; without even the implied warranty of +.. * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +.. * GNU General Lesser Public License for more details. +.. * +.. * You should have received a copy of the GNU General Lesser Public +.. * License along with this program. If not, see +.. * <http://www.gnu.org/licenses/lgpl-3.0.html>. +.. * #L% +.. - +====================================== +Générer son modèle métier vers Wikitty +====================================== + +Modélisation +============ + +Vous pouvez modéliser votre modèle métier en utilisant n'importe quel modéliseur +UML pouvant enregistrer le modèle au format xmi (ArgoUML, Topcased,...). Les +entités que vous souhaitez générer doivent avoir le stéréotype *entity*. + +Configuration Maven +=================== + +Pour générer le code, nous utilisons EUGene_ et son plugin Maven. + +Dans le pom de votre projet, rajoutez la définition du plugin:: + + <plugin> + <groupId>org.nuiton.eugene</groupId> + <artifactId>maven-eugene-plugin</artifactId> + <version>${eugeneVersion}/version> + <executions> + <execution> + <id>api generator</id> + <phase>process-sources</phase> + <configuration> + <inputs> + <input>zargo:src/main/xmi/:*.zargo</input> + <input>classpath:model:/:wikitty.objectmodel + </input> + </inputs> + <fullPackagePath>your.app.package</fullPackagePath> + <defaultPackage>your.app.package</defaultPackage> + <extractedPackages> + your.app.package,org.nuiton.wikitty + </extractedPackages> + <generatedPackages>your.app.package</generatedPackages> + <templates> + org.nuiton.wikitty.generator.WikittyMetaGenerator, + org.nuiton.wikitty.generator.WikittyDTOGenerator + </templates> + </configuration> + <goals> + <goal>smart-generate</goal> + </goals> + </execution> + </executions> + </plugin> + +Dans la section *inputs*, on spécifie le(s) modèle(s) métier:: + + zargo:src/main/xmi/:*.zargo + +ainsi que le modèle Wikitty (en cas de dépendance de votre modèle métier vers le +modèle Wikitty). + +Dans la section *templates*, vous pouvez spécifier quoi générer : +*org.nuiton.wikitty.generator.WikittyMetaGenerator* pour la génération Wikitty +standard et *org.nuiton.wikitty.generator.WikittyDTOGenerator* pour la +génération des DTOs si besoin (utilisation d'une UI GWT par exemple). + +Génération +========== + +La génération est effectuée ensuite à chaque fois que vous lancez un build. + +Subtilités de modélisation +========================== + +Dépendances vers l'API de Wikitty +--------------------------------- + +Il est possible de rajouter une dépendance vers un objet de l'API Wikitty (par +example WikittyUser) en rajoutant simplement la classe dans votre modèle dans le +package* org.nuiton.wikitty.api*. Elle ne sera pas générée mais interviendra +comme une autre classe de votre modèle (héritage,...). + +.. image:: wikittyDependency.png + +Arbres +------ + +Si vous souhaitez qu'une entité crée un arbre, vous avez juste à faire hériter +cette entité de WikittyTreeNode (pas besoin de référence sur elle-même). De +cette manière, la gestion de l'arbre est assurée par Wikity, de même que +l'indexation et la recherche. + +.. image:: wikittyTree.png + +.. _EUGene::http://maven-site.nuiton.org/eugene/ \ No newline at end of file Property changes on: trunk/src/site/rst/user/generation.rst.vm ___________________________________________________________________ Added: svn:keywords + Author Date Id Revision HeadURL Modified: trunk/src/site/rst/user/security.rst =================================================================== --- trunk/src/site/rst/user/security.rst 2011-03-04 10:55:53 UTC (rev 742) +++ trunk/src/site/rst/user/security.rst 2011-03-04 13:30:30 UTC (rev 743) @@ -20,9 +20,15 @@ Cela rajoute la couche de sécurité à Wikitty. Vous pouvez maintenant rajouter des droits à certaines entitées pour en limiter l'accès. -Création de l'administrateur de l'application ---------------------------------------------- +Utilisateurs et groupes +----------------------- +Dans Wikitty, deux notions sont utilisées pour gérer la sécurité : les +utilisateurs (WikittyUser) et groupes (WikittyGroup). + +Les utilisateurs ont un identifiant et un mot de passe, les groupes contiennent +des utilisateurs et d'autres groupes. + Par défaut il existe un *WikittyGroup* portant le nom **WikittyAppAdmin**. Si ce groupe n'existe pas ou qu'il est vide, cela indique que tous les utilisateurs sont AppAdmin. Cela est nécessaire pour deux choses: @@ -37,6 +43,27 @@ Il ne doit donc exister un seul *WikittyGroup* portant le nom **WikittyAppAdmin** +L'authentification et les tokens de sécurité +-------------------------------------------- + +À chaque login, un token de sécurité est fourni à l'utilisateur. L'utilisateur +doit fournir ce token à chaque opération pour montrer qu'il a les droits. +Pour un token donné, on peut savoir à quel utilisateur il appartient. Pour le +développeur, cela n'implique pas de changement car le token de sécurité est +conservé par le **WikittyProxy**. Il faut juste faire attention à bien avoir un +WikittyProxy par utilisateur. Dans le cas d'applications web, il est conseillé +de conserver le proxy dans la session de l'utilisateur. + +Les tokens sont stockés en base et supprimés au logout de l'utilisateur. + +Les SecurityToken ne sont supprimés de la base de données qu'au moment du logout +Si les utilisateurs/applications quittent sans faire le logout le nombre de +SecurityToken ne fera qu'augmenter. Pour éviter cela, il faut prévoir un petit +job qui de temps en temps fait le ménage dans les SecurityToken trop vieux. + +Création de l'administrateur de l'application (AppAdmin) +-------------------------------------------------------- + La première chose à faire maintenant, est donc de créer l'utilisateur administrateur de l'application et l'ajouter au groupe **WikittyAppAdmin**:: @@ -47,17 +74,19 @@ WikittyGroup adminGroup = WikittySecurityUtil.createAppAdminGroup(admin); +Note : il faut vérifier que le groupe existe avant de le créer). + Jouer avec les droits sur une entité (sécurité de niveau 1) ----------------------------------------------------------- A partir de maintenant, l'utilisateur administrateur (et tous les autres -utilisateurs faisant partie du groupe des **AppAdmin**) peut ajouter/retirer +utilisateurs faisant partie du groupe **WikittyAppAdmin**) peut ajouter/retirer des droits à des entités. -Par exemple, pour rajouter les droits de lecture a un utilisateur (l'utilisateur +Par exemple, pour rajouter les droits de lecture à un utilisateur (l'utilisateur admin est déjà identifié) sur un wikitty:: - //On commence par charger les wikittys concernés + //On commence par charger les wikitties concernés WikittyAuthorisation skill = proxy.restore(WikittyAuthorisation.class, id); //On ajoute en reader notre utilisateur @@ -92,20 +121,69 @@ owner en tant que reader. Car de toute façon l'owner aura toujours le droit en lecture. -L'authentification ------------------- +La granularité des droits se situe donc au niveau de chaque instance. On doit +pouvoir définir le droit pour chaque extension, de chaque wikitty. Il n'y a +pas de gestion des droits par champs. Avoir le droit *reader* sur une extension +d'un wikitty donne le droit de lecture sur tous les champs de cette extension. -À chaque login, un token de sécurité est fourni à l'utilisateur. L'utilisateur -doit fournir ce token à chaque opération pour montrer qu'il a les droits. -Pour un token donné, on peut savoir à quel utilisateur il appartient. Pour le -développeur, cela n'implique pas de changement car le token de sécurité est -conservé par le **WikittyProxy**. Il faut juste faire attention à bien avoir un -WikittyProxy par utilisateur. Dans le cas d'applications web, il est conseillé -de conserver le proxy dans la session de l'utilisateur. +La granularité des droits se situe donc au niveau de chaque instance. On doit +pouvoir définir le droit pour chaque extension, de chaque wikitty. Il n'y a +pas de gestion des droits par champs. Avoir le droit *reader* sur une extension +d'un wikitty donne le droit de lecture sur tous les champs de cette extension. -Les tokens sont stockés en base et supprimés au logout de l'utilisateur. +Différence entre Admin et AppAdmin +---------------------------------- -Les SecurityToken ne sont supprimés de la base de données qu'au moment du logout -Si les utilisateurs/applications quittent sans faire le logout le nombre de -SecurityToken ne fera qu'augmenter. Pour éviter cela, il faut prévoir un petit -job qui de temps en temps fait le ménage dans les SecurityToken trop vieux. \ No newline at end of file +Un admin est administrateur d'une entité uniquement, alors qu'un AppAdmin est +administrateur de toutes les entités de l'application. + +Stockage des droits de niveau 1 en base de donnée +------------------------------------------------- + +Du point de vue structure de données, les droits sont stockés sur le wikitty +lui-même, dans des champs spécifiques. Par exemple, si le wikitty porte +l'extension *Ext*, il portera également l'extension « Ext:WikittySecurity » +et il y aura, sur le Wikitty, un champ nommé « owner » (dont le FQN est +« Ext:WikittySecurity.owner »). + +Autre exemple, si un Wikitty porte 3 extensions, ayant chacune 10 champs. +Le wikitty aura, au total, 42 champs : 3 × 10 champs + 3 extensions × 4 champs +(les 4 champs de l'extension WikittySecurity). + +Jouer avec les droits sur les extensions (sécurité niveau 2) +------------------------------------------------------------ + +Pour chaque extension, on a la même hiérachie de droit qui donnent des +possibilités différentes : + ++----------+----------------------+----------+-------------+----------------------+ +| Type | Lecture/ | Ecriture | Suppression | Changement de droits | +| | Création d'instances | | | | ++==========+======================+==========+=============+======================+ +| Reader | X | | | | ++----------+----------------------+----------+-------------+----------------------+ +| Writer | X | X | | | ++----------+----------------------+----------+-------------+----------------------+ +| Owner | X | X | X | | ++----------+----------------------+----------+-------------+----------------------+ +| Admin | X | X | X | X | ++----------+----------------------+----------+-------------+----------------------+ +| AppAdmin | X | X | X | X | ++----------+----------------------+----------+-------------+----------------------+ + +Si le reader est vide, tout le monde peut créer des instances de l'extension. +Pour que seuls les AppAdmin et le owner puissent créer des instances, il faut +mettre le owner en reader. + +Si une extension ne dispose pas de ces informations, seuls les AppAdmin peuvent +créer les instances et modifier l'extension. + +Stockage des droits de niveau 2 en base de donnée +------------------------------------------------- + +Ces droits sont stockés sous le forme d'un Wikitty. Pour chaque extension +connue, il y aura donc un Wikitty dont la seule extension sera WikittySecurity. + +Chacun de ces wikitty aura pour identifiant « WikittySecurity:ExtensionName ». +Cela permet de court-cuircuiter la recherche solR, et un passage par le réseau à +chaque store/restore. \ No newline at end of file Modified: trunk/src/site/site_fr.xml =================================================================== --- trunk/src/site/site_fr.xml 2011-03-04 10:55:53 UTC (rev 742) +++ trunk/src/site/site_fr.xml 2011-03-04 13:30:30 UTC (rev 743) @@ -26,60 +26,61 @@ <project name="${project.name}"> - <publishDate format="dd/MM/yyyy"/> + <publishDate format="dd/MM/yyyy"/> - <bannerLeft> - <name>${project.name}</name> - <href>index.html</href> - </bannerLeft> + <bannerLeft> + <name>${project.name}</name> + <href>index.html</href> + </bannerLeft> - <body> + <body> - <breadcrumbs> - <item name="${project.name}" href="${project.url}"/> - </breadcrumbs> + <breadcrumbs> + <item name="${project.name}" href="${project.url}"/> + </breadcrumbs> - <links> - <item name="Libre-Entreprise" - href="http://www.libre-entreprise.org/"/> - <item name="[fr" href="index.html"/> - <item name="en]" href="en/index.html"/> - </links> + <links> + <item name="Libre-Entreprise" + href="http://www.libre-entreprise.org/"/> + <item name="[fr" href="index.html"/> + <item name="en]" href="en/index.html"/> + </links> - <menu name="Overview"> - <item name="Accueil" href="index.html"/> - <item name="Fonctionnement" href="fonctionnement.html"/> - <item name="Fonctionnalités" href="features.html"/> - <item name="Changements" href="changes.html"/> - </menu> + <menu name="Overview"> + <item name="Accueil" href="index.html"/> + <item name="Fonctionnement" href="fonctionnement.html"/> + <item name="Fonctionnalités" href="features.html"/> + <item name="Changements" href="changes.html"/> + <item name="Spécifications" href="Spec.html"/> + </menu> - <menu name="Utilisateur"> - <item name="Génération" href="user/generation.html"/> - <item name="Migration" href="user/migration.html"/> - <item name="Hessian" href="user/hessian.html"/> - <item name="Sécurité" href="user/security.html"/> - </menu> + <menu name="Utilisateur"> + <item name="Génération" href="user/generation.html"/> + <item name="Migration" href="user/migration.html"/> + <item name="Hessian" href="user/hessian.html"/> + <item name="Sécurité" href="user/security.html"/> + </menu> - <menu name="Developpeur"> - <item name="Todo" href="todo.html"/> - </menu> + <menu name="Developpeur"> + <item name="Todo" href="todo.html"/> + </menu> - <menu name="Communauté"> - <item name="Bug tracker" - href="http://nuiton.org/projects/wikitty/issues"/> - <item name="Téléchargement" - href="http://nuiton.org/projects/list_files/wikitty"/> - <item name="Dépot SVN" - href="http://svn.nuiton.org/svn/wikitty/"/> - <item name="Intégration continue" - href="http://hudson.nuiton.org/hudson/job/wikitty/"/> - <item name="Analyse Sonar" - href="http://sonar.nuiton.org/sonar/project/index/org.nuiton:wikitty"/> - </menu> + <menu name="Communauté"> + <item name="Bug tracker" + href="http://nuiton.org/projects/wikitty/issues"/> + <item name="Téléchargement" + href="http://nuiton.org/projects/list_files/wikitty"/> + <item name="Dépot SVN" + href="http://svn.nuiton.org/svn/wikitty/"/> + <item name="Intégration continue" + href="http://hudson.nuiton.org/hudson/job/wikitty/"/> + <item name="Analyse Sonar" + href="http://sonar.nuiton.org/sonar/project/index/org.nuiton:wikitty"/> + </menu> - <menu ref="modules"/> + <menu ref="modules"/> - <menu ref="reports"/> + <menu ref="reports"/> - </body> + </body> </project> \ No newline at end of file