Cette application WEB est regroupe l'ensemble des fonctions d'administration de Dynacase-platform et des modules Dynacase. Elle est accessible sous le répertoire webstudio à partir de l'url du serveur Dynacase.

Les modules sont administrés via des services d'administration. Un service fournit une interface graphique qui donne accès à un ensemble de fonctionnalités.

Les services sont associées aux applications, chaque application pouvant apporter un à plusieurs services qui apparaîtront automatiquement dans le webstudio.

Son interface est composée de 3 parties distinctes :

• une barre supérieure offrant les fonctions de connexion, etc. ¹⁾
• la liste des services à gauche un accordéon regroupe les services, chacun des services étant matérialisé par un item de l'accordéon. Lorsque l'item est ouvert, la zone de l'accordéon propose un espace dédié au service.
• l'interface du service : partie de droite affiche le contenu du service sélectionné

La liste des service peut être dépliée / repliée.
La liste des service ne présente que ceux pour lesquels l'utilisateur connecté a le droit. La liste des services est présentée sous forme d'arbre, dans lesquels les services sont répartis en trois rubriques : Webstudio -pour les services liées au webstudio en lui même-, Platform -pour les services liées à la plateforme Dynacase-platform de base, Applications -pour les services apportés par des applications installées. Il peut y avoir une profondeur de premier niveau de sous-services sous chaque service, qui se déroule sous le nœud concerné.

La partie de droite conserve le contexte : le passage d'un service à un autre et le retour au premier la laisse identique à ce qu'elle était initialement.

L'administrateur général admin accède à l'ensemble des fonctions d'administration sans limitation.

Les administrateurs délégués sont des utilisateurs Dynacase à qui l'administrateur général a donné les droits d'administration sur un ou plusieurs services.

L'interface est développée sur les composants freedom-extui et en ExtJS.

Le centre d'administration Dynacase est distribué sous forme du module freedom-admin.

Le CAF est accessible via un lien disponible sur l'interface Dynacase-control et calculé en fonction de l'URL Dynacase ²⁾.

L'api Dynacase et les règles de développement précisent comment un module peut ajouter un ou plusieurs services d'administration.

Chaque application est livrée avec un .xml qui contient les informations sur les services qu'elle ajoute.

Les services peuvent être décrits sous la forme d'url relatives au serveur Dynacase (voir à ce sujet l'utilisation du script sudo.php qui permet d'agir avec les droits de l'administrateur Dynacase) ou sous la forme de widget javascript ExtJS. Exemple d'un fichier application.xml

 
<?xml version="1.0" encoding="utf-8" ?>
<application name="WEBSTUDIO" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="application.xsd"  >
 
	<identification>		
		<label>Webstudio</label>
		<description>Webstudio Administration Interface</description>
		<freeaccess>true</freeaccess>
		<icon>core.png</icon>
		<displayable>false</displayable>
		<htmlheaders>true</htmlheaders>		
	</identification>
 
	<services>
 
		<service name='WEBSTUDIO_USERS'>
			<label>Utilisateurs Webstudio</label>
			<widget>Ext.fdl.WebstudioUserPanel</widget>
			<icon>../lib/ui/icon/application.png</icon>
		</service>
		<service name='APPLICATION_MANAGER_URL'>
			<label>Applications</label>
			<url>sudo.php?sole=A&amp;app=APPMNG&amp;action=APPLIST</url>
			<icon>../APPMNG/Images/appmng.gif</icon>
		</service>
		<service name='APPLICATION_MANAGER_WID'>
			<label>Applications (ExtJS)</label>
			<component>Ext.fdl.AppMngPanel</component>
			<icon>../APPMNG/Images/appmng.gif</icon>
		</service>
		<service name='AUTHENTIFICATION'>
			<label>Authentification</label>
			<url>sudo.php?sole=A&amp;app=ACCESS</url>
			<icon>../Images/access.gif</icon>
		</service>
		<service name='USERS'>
			<label>Utilisateurs</label>
			<url>sudo.php?sole=A&amp;app=FUSERS</url>
			<icon>../Images/users.gif</icon>
			<subservice name='SUBUSERS1'>
				<label>Sous-Utilisateurs 1</label>
				<url>sudo.php?sole=A&amp;app=FUSERS</url>
				<icon>../Images/users.gif</icon>
			</subservice>		
			<subservice name='SUBUSERS2'>
				<label>Sous-Utilisateurs 2</label>
				<url>sudo.php?sole=A&amp;app=FUSERS</url>
				<icon>../Images/users.gif</icon>
			</subservice>
		</service>
 
		<service name='GOOGLE'>
			<label>Google</label>
			<url>http://www.google.com</url>
			<icon>../lib/ui/icon/application.png</icon>
		</service>
 
	</services>
 
</application>

Les services permettent de lancer des actions sur le système Dynacase en empruntant les droits de super-utilisateur Dynacase.

Chaque service déclare éventuellement des actions spécifiées de la façon suivante :

<service name='WEBSTUDIO_USERS'>
	<label>Utilisateurs Webstudio</label>
	<widget>Ext.fdl.WebstudioUserPanel</widget>
	<icon>../lib/ui/icon/application.png</icon>
	<action name='my_action'>
		<url></url>
		<param>
			<key>app</key>
			<value>FREEDOM</value>
		</param>
		<param>
			<key>action</key>
			<value>FDL_CARD</value>
		</param>
		<param>
			<key>id</key>
			<value>9</value>
		</param>
 
	</action>
	<action name='my_action_2'>
		<url></url>
		<param>
			<key>app</key>
			<value>FREEDOM</value>
		</param>
		<param>
			<key>action</key>
			<value>FDL_CARD</value>
		</param>
		<param>
			<key>id</key>
			<value>9</value>
		</param>
 
	</action>
</service>

Le script sudo prend en paramètre un identifiant logique d'action. Il exécute cette action en mode administrateur Dynacase seulement si l'utilisateur webstudio courant possède bien l'ACL sur le service donnant l'action. Les balises définies servent concrètement à composer l'url appelée sur le serveur Dynacase.

- url permet de définir l'adresse à appeler pour l'action

- param permet de définir un paramètre obligatoire de l'action, qui ne pourra pas être redéfini dynamiquement par l'appel client

Ces balises 'param' correspondent donc à des paramètres pour l'action qui ne sont pas modifiables lors de l'appel, mais il est possible de rajouter des paramètres supplémentaires parmi ceux qui ne sont pas spécifiés explicitement.

Le composant javascript Ext.fdl.AdminPanel propose une méthode pour appeler en ajax de façon simple une action ainsi définie

Ext.fdl.AdminPanel.webstudioAction(config), config étant un objet de configuration avec les attributs suivants :

- action : <string> l'identifiant logique de l'action à appeler, obligatoire.

- params : {} un objet contenant des paramètres supplémentaires à envoyer lors de l'appel

- success : function(response,options) la fonction de callback du retour de l'appel, similaire à celle définie dans ExtJS

- failure : function(response,options) la fonction de callback d'erreur de l'appel, similaire à celle définie dans ExtJS

Remarques :

- pas nécessaire de spécifier url (forcément Dynacase)

- rendre la balise app et la balise action obligatoire

- regarder les mécanismes de validation de la syntaxe xml côté php pour le développeur

Un service de gestion des utilisateurs de webstudio est automatiquement disponible.

L'accès au WebStudio nécessite une authentification.

Les utilisateurs sont stockés dans un fichier XML webstudio-users.xml.

<users>
    <session timeout="<string>"/>
    <user>
        <superuser>1</superuser>
        <login>admin</login>
        <password>*******</password>
        <description>"<string>"</description>
    </user>
    <user>
        <login>"<string>"</login>
        <password>******</password>
        <description>"<string>"</description>
        <services id="<service name>">
            "<service label>"
         </services>
         <services id="<service name>">
            "<service label>"
        </services>
    </user>
</users>

Pour chacun des utilisateurs, les services auquel a accès l'utilisateur sont listés. Lors de la première connexion au WebStudio, lorsque le fichier Xml n'existe pas, le WS demande le mot de passe de l'administrateur général et initialise le fichier.

Le service de gestion des utilisateurs WebStudio permet :

• ajouter un utilisateur : un formulaire demande le login, le mot de passe (double saisie) et la description. si le login et le mot de passe sont validés le compte est enregistré dans le fichier XML. Le mot de passe est crypté (injection).
• supprimer un utilisateur : après confirmation : la suppression est réalisée dans le fichier XML. Le compte admin ne peut être supprimé.
• modifier les informations relatives aux utilisateurs : un interface similaire à la création (le login n'est pas modifiable) permet de modifier le mot de passe (double saisie) et la description.
• de gérer les ACL aux services pour chacun des utilisateurs (hors admin)

Un bannière HTML propose à l'utilisateur de saisir son login et son mot de passe. Le contrôle est réalisé, s'il est positif l'utilisateur accède alors à l'interface générale. Les services disponibles sont ceux pour lesquels l'accès est explicitement donné dans le fichier utilisateur. Sur l'interface (bandeau supérieur) l'utilisateur peut accéder à la fenêtre de modification de ses informations (cf. ci dessus). Un bouton lui permet de se déconnecter.

L'interface doit permettre d'assigner des utilisateurs dans des groupes. Plus précisément, il est important de pouvoir manipuler plusieurs utilisateurs regroupés par la notion de panier, et de pouvoir cibler ensuite un groupe unitairement.

Voilà la proposition que je fais :

L'interface se présente soit sous la forme de trois colonnes, soit sous la forme de deux colonnes et d'un bloc en dessous.

La colonne de gauche présente un arbre affichant les groupes. Noter qu'il y a le groupe 'all users' qui contient à chaque instant tous les utilisateurs du système, ce qui évite de perdre un utilisateur 'orphelin'. Une action dans le menu permet d'ajouter, d'éditer, ou de supprimer un groupe (dans ce cas, les utilisateurs qu'il contient ne sont pas automatiquement supprimés).

Lorsqu'un groupe est cliqué, la colonne du milieu affiche une grid qui contient les utilisateurs du groupe sélectionné. Les groupes contenus dans celui ci sont aussi affichés, et peuvent être manipulés exactement comme des utilisateurs. Ces utilisateurs et ces groupes d'utilisateurs peuvent être sélectionnés (multi-sélection possible). L'action de la barre de menu 'User' permet de créer un nouvel utilisateur dans ce groupe, de retirer un ou des utilisateur(s) du groupe, de supprimer le ou les utilisateur(s), d'éditer l'utilisateur. L'action de la barre de menu 'selection' permet d'ajouter la sélection courante dans le panier d'utilisateurs, qui est une grid soit en 3e colonne, soit dans le bloc du bas. Sur la barre du haut, un champ de texte permet de faire un filtre sur les utilisateurs et les groupes présentés par rapport à leur nom (un bouton sert à valider le filtre, un autre à le nettoyer).

Au niveau du panier d'utilisateur, un bouton permet d'ajouter tout le contenu au groupe actuellement sélectionné, ou d'ajouter les utilisateurs sélectionnés (la seconde colonne est alors réactualisée immédiatement de son contenu). Un bouton permet de retirer tous les utilisateurs du panier, ou tous les utilisateurs sélectionnés.

- Remarque :

- attention à la logique de tri (majuscule, minuscule, accents, etc.)

- grouping par groupes et par utilisateurs

- dans le menu sélection, déplacer dans le panier

- accéder directement au ACL depuis un groupe ou un utilisateur

- créer l'interface pour créer / éditer un utilisateur / un groupe

- liste des actions Dynacase : lister les groupes, créer un groupe, éditer un groupe, supprimer un groupe (avec ou sans ses utilisateurs), obtenir le contenu d'un groupe, créer un utilisateur, éditer un utilisateur, supprimer un utilisateur, ajouter des utilisateurs/groupes à un groupe, retirer des utilisateurs/groupes à un groupe.

La partie de gauche présente des onglets (tabpanel). La partie de droite est une partie d'affichage variable.

Les onglets disponibles sont :

- Users & Groups : un arbre des groupes est disponible, lorsqu'on clique sur un groupe, la partie de droite fait apparaitre, soit une arborescence des applications, soit une grille des ACL groupées par application. Chaque nœud représente une application, et ses enfants les différentes ACL qu'elle contient. Un indicateur indique si l'ACL est autorisée par héritage. Un autre indicateur indique si l'ACL est validée ou annulée pour ce groupe (surcharge de l'héritage). Une barre d'outil en haut donne les actions suivantes : valider un ACL, annuler une ACL, sauver tout, annuler tout.

- remarque : système de boutons à définir

Problème : afficher unitairement les utilisateurs d'un groupe ? Faire un onglet Users spécifique vers qui permet de rechercher des utilisateurs dans une interface de grille avec un filtre sur le groupe ? Et permettre qu'un double clic sur le groupe dans l'onglet 'groups' ouvre automatiquement l'onglet users avec le filtre sur le groupe souhaité ?

- App ACL : un arbre des applications avec leur ACL est disponible, lorsqu'on clique sur une ACl, la partie de gauche montre une arborescence-grille des groupes. Les coches permettent de valider l'acl pour un groupe et ses enfants. Si on clique sur une coche héritée, on retire explicitement l'ACL du groupe. Dans la barre d'outil, les actions suivantes : sauver tout, annuler tout.

Problème : afficher unitairement les utilisateurs d'un groupe ? Ou faire des onglets pour afficher séparément les groupes et les utilisateurs ?

- remarque : - pas de filtre pour le moment, - on garde les utilisateurs dans les nœuds