Ouverture & Innovation

Workflow de demande de congés eGroupWare

Nicolas — Mon, 16 Jun 2008 14:55:00 +0200

Le module WorkFlow d'eGroupWare permet, comme son nom l'indique, de gérer des workflow, c'est à dire des processus internes au sein d'eGroupWare.

Ce module est basé sur le moteur de Workflow OpenSource Galaxia. La documentation sur le module WorkFlow d'eGroupWare est pour le moment très limitée, celle de Galaxia est donc d'une grande aide.

Les possibilités de création de processus sont nombreuses grâce à l'accès à l'API d'eGroupWare (langage PHP)

Principe et nomenclature

Les processus gérés par le module WorkFlow sont divisée en activités reliées par des transitions.
Une activité peut être interactive, c'est à dire qu'un utilisateur va devoir effectuer une action.
La gestion des droits s'effectue à l'aide de rôles.
Chaque lancement d'un processus est une instance.

Création d'un processus

La première étape de création d'un processus est sa modélisation:

assignation des rôles à des utilisateurs/groupes, des
création des activités (au minimum deux: start et end)
rattachement des activités entre elles

On peut alors visualiser le cheminement via un graphique

La deuxième étape consiste à développer les activités interactives à l'aide d'une interface donnant accès au code PHP et au template html.
Il est possible d'ajouter un agent SMTP à une au plusieurs activités d'un processus afin d'envoyer des mails.
Il est aussi possible d'interagir avec les autres modules d'eGroupWare. Par exemple, l'ajout d'un événement dans le calendrier.

Processus de demande de congés

Voici un exemple de processus de gestion d'une demande de congés:

L'utilisateur demande un congé en indiquant une plage de date sur eGroupWare.
Le validateur reçoit un email lui indiquant qu'une demande de congé a été effectuée. (agent mail_smtp)
Le validateur valide, ou non, cette demande sur eGroupWare.
Si la demande est validée, la plage de congés est incluse dans le calendrier eGroupWare.
L'utilisateur reçoit un email lui indiquant que sa demande de congé a été traitée. (agent mail_smtp)

Graphique:

Interfaces graphiques avec AutoIT3 et KODA

Pierre — Fri, 02 May 2008 18:07:00 +0200

Suite à notre article sur le langage de script AutoIT 3 (lire l'article), cet article a pour but de présenter le programme permettant de créer rapidement des interfaces graphiques avec AutoIT, à la manière du Form Designer du Visual Basic.

Rappel

AutoIT3 (adresse) est un langage de script concurrent du langage KiXtart utilisé notamment pour l'administration de parc Windows. Il présente un langage simple à appréhender, puissant et de nombreux modules ont été créés pour ajouter de nouvelles fonctionnalités. Certaines de ces fonctionnalités feront l'objet d'un article.

Présentation

KODA est un programme additionnel à AutoIT3 pour concevoir ses IHM de manière graphique. Vous pouvez le télécharger à partir du forum d'AutoIT3 : http://www.autoitscript.com/forum/index.php?showtopic=32299&hl=koda. L'interface peut être sauvegardée au format kxf (xml) pour être remodifiée par la suite. Le format de sortie final de KODA est cependant du code AutoIT3 définissant l'interface. A la différence du Visual Basic qui stocke ses frames (interface + code) dans des fichiers séparés intégrés à la compilation, AutoIT3 intègre le code de génération des interfaces directement dans le fichier source « au3 ».

Description de l'interface

L'interface est découpée en différents blocs : En haut, la barre de menus, les boutons d'ouverture/sauvegarde, d'exécution et d'import (nous y reviendrons par la suite) et les contrôles à insérer dans le formulaire. Au milieu à gauche, l'Object TreeView qui montrera l'organisation hiérarchique entre les différents objets. Il s'agit d'un « explorateur » de fenêtre. Au centre, la fenêtre vierge sur laquelle nous travaillons. A droite, la « Form List » qui permet de gérer différentes fenêtres. En bas à gauche, l'« Object Inspector » qui permet de régler les différents paramètres de chaque élément de la fenêtre (nom, contenu textuel, taille...)

Utilisation de l'interface

Pour placer un contrôle sur la fenêtre, il suffit de cliquer sur le contrôle désiré, puis sélectionner une zone sur la fenêtre en faisant un glisser-déposer.

Exemple : Voir ci-dessous, nous venons de placer un bouton sur l'interface.

Si on souhaite le déplacer, il suffit de cliquer dessus pour le sélectionner, puis faire un glisser-déposer jusqu'à sa destination.

L'inspecteur d'objet

L'inspecteur d'objet permet de régler finement l'apparence de vos contrôles (taille, couleur, police...). Il permet également de spécifier le contenu textuel de vos zones de texte (champ caption), ainsi que le nom de votre contrôle (champ name). Dans un souci de clarté de code, nous vous recommandons de définir les noms des contrôles que vous allez utiliser dans votre programme (lire une valeur d'un champ, détecter un clic sur un élément...).

Dans l'exemple suivant, le bouton a été nommé « ButValid » et contient le texte « Continuer ».

Export et intégration dans votre programme AutoIT3.

Les deux boutons à droite du bouton d'enregistrement servent respectivement à afficher le code source AutoIT3 et à prévisualiser l'interface. -Le premier affichera le code source dans une petite fenêtre avec un bouton pour copier le code dans le presse-papier.

Voici un exemple de notre fenêtre pour afficher un contrat de licence et demander l'acceptation de celui-ci :

#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>

#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("Form1", 633, 447, 1561, 164)
$ButValid = GUICtrlCreateButton("Continuer", 424, 400, 121, 25, 0)
$Label1 = GUICtrlCreateLabel("Label1", 8, 8, 620, 377)
GUICtrlSetBkColor(-1, 0xFFFFFF)
$Radio1 = GUICtrlCreateRadio("Oui", 272, 392, 121, 25)
$Radio2 = GUICtrlCreateRadio("Non", 272, 416, 121, 25)
$Label2 = GUICtrlCreateLabel("Acceptez-vous les termes du contrat de licence ?", 24, 400, 237, 17)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###

While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit

	EndSwitch
WEnd

-Le deuxième va directement ouvrir l'éditeur Scite avec le code source présent. L'intérêt est de pouvoir tester en grandeur nature ce à quoi l'interface va ressembler à l'exécution. Appuyez simplement sur la touche <F5> pour lancer le programme.

Interagir avec les contrôles dans le code

Détecter un clic :

Le switch GUIGetMsg() permet de savoir quel contrôle envoie un événement. Pour savoir si notre bouton a été pressé, il suffit de rajouter un Case $NomDuControle. La boucle ressemble alors à cela :

While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
		Case $ButValid
			MsgBox(0,''Bouton pressé'',''C'est le bouton continuer qui a été pressé'')
	EndSwitch
WEnd

Ce code permettra d'avoir une alerte qui s'affichera lorsque l'utilisateur cliquera sur le bouton « Continuer ».

De manière générale, tout contrôle est cliquable, dans la mesure où l'on peut intercepter l'évènement via cette boucle.

Obtenir les paramètres des contrôles

Nous avons placé deux boutons radio permettant de savoir si l'utilisateur a accepté ou non la licence. Il serait intéressant de savoir quel bouton a été coché pour agir en conséquence. Pour cela, il suffit d'utiliser la fonction GUICtrlRead avec la variable du contrôle en paramètre. Ce qui donne le code suivant :

While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
		Case $ButValid
			if GUICtrlRead($Radio1) = 1 Then
				msgbox(0,"Merci","Vous avez accepté le contrat de licence !")
				;Insert installation code here
			Else
				msgbox(0,"Erreur","Vous n'avez pas accepté le contrat de licence !")
				Exit
			EndIf
	EndSwitch
Wend

Conclusion

AutoIT3 est déjà en soi un outil puissant pour réaliser nombre de tâches d'administration ou autre. Grâce à KODA, la création d'interfaces graphiques devient encore plus simple et augmente le potentiel du langage pour un investissement en temps minimal. Cet article ne couvre qu'une partie des possibilités de KODA et du système d'interface graphique de manière générale, mais il permet au développeur néophyte de connaître les fonctions de base pour commencer à créer une interface graphique pour ses programmes. Pour plus d'informations, le mieux est de consulter la documentation officielle d'AutoIT3, surtout les fonctions commençant par « GUI ». Chaque fonction est commentée et comporte un exemple.

Annexe

Voici le code source de la fenêtre d'acceptation de licence :

#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>

#Region ### START Koda GUI section ### Form=
$Form1 = GUICreate("Form1", 633, 447, 1561, 164)
$ButValid = GUICtrlCreateButton("Continuer", 424, 400, 121, 25, 0)
$Label1 = GUICtrlCreateLabel("Please Insert License Here", 8, 8, 620, 377)
GUICtrlSetBkColor(-1, 0xFFFFFF)
$Radio1 = GUICtrlCreateRadio("Oui", 272, 392, 121, 25)
$Radio2 = GUICtrlCreateRadio("Non", 272, 416, 121, 25)
$Label2 = GUICtrlCreateLabel("Acceptez-vous les termes du contrat de licence ?", 24, 400, 237, 17)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###



 While 1
 	$nMsg = GUIGetMsg()
 	Switch $nMsg
 		Case $GUI_EVENT_CLOSE
 			Exit
 		Case $ButValid
 			if GUICtrlRead($Radio1) = 1 Then
 				msgbox(0,"Merci","Vous avez accepté le contrat de licence !")
 				;Insert installation code here
 			Else
 				msgbox(0,"Erreur","Vous n'avez pas accepté le contrat de licence !")
				Exit
 			EndIf
 	EndSwitch
 WEnd

Quel est le TCO d'Office 2007 ?

Benoît — Thu, 08 Nov 2007 17:14:00 +0100

A l'heure actuelle, dans une organisation, lorsqu'est menée la réflexion sur l'évolution, voire le changement, de suite bureautique, la question de l'arbitrage du TCO (ou "coût total de possession") se pose rapidement. C'est un calcul savant mais parfois aléatoire qui permet de déterminer l'ensemble des coûts générés par la possession d'un logiciel bien au-delà du simple coût de licence. C'est donc une variable essentielle de prise de décision.

Lorsque l'on décide de comparer la migration de Microsoft Office à OpenOffice, il est naturel d'inclure dans ce calcul des éléments de coûts tels que :

La formation des employés à une interface un peu différente,
La gestion du format de document OpenDocument et les relations avec les correspondants extérieurs à l'organisation,
Les coûts de déploiement et d'administration d'un produit non Microsoft,
La compatibilité éventuelle des macros et des applications métiers.

Si dans l'esprit des décideurs, ces éléments de calcul du TCO pour OpenOffice sont assez naturels et répandus, il est beaucoup plus rare que ce même raisonnement soit appliqué pour Microsoft Office 2007 alors qu'il a encore toute raison d'être.

Formation du personnel

Si l'on considère, à juste titre, que le saut d'Office 2000, XP ou 2003 à OpenOffice nécessite impérativement une formation des équipes, que dire alors pour Office 2007 ? Le ruban de l'interface d'Office 2007 est vendu comme la révolution ultime de l'interface utilisateur. Il l'est peut-être, mais à cause de cela, il rend l'interface utilisateur extrêmement différente de la classique interface bureautique. On peut raisonnablement penser qu'OpenOffice est plus proche d'une interface bureautique classique qu'Office 2007.
Passons à la comparaison :

Office 2003:

OpenOffice 2.3:

Office 2007:

La première et la deuxième copie d'écran sont presque identiques. Ils ont des icônes de mise en page similaires (nouveau, ouvrir, enregistrer, e-mail, etc.), des menus déroulants etc... Office 2007 change tout. Certains icônes sont cachés, d'autres sont au mauvais endroit. Certains menus n'existent pas, les barres d'outils sont par onglets etc...

Les utilisateurs auront à développer de nouvelles habitudes et de réflexes bureautiques.

Formats de fichier et compatibilité

Il est un élément qui est moins présent dans les esprits que pour OpenOffice, c'est qu'Office 2007 arrive également avec un nouveau format de document : le format OpenXML, renvoyant instantanément au placard le bon vieux format de fichier de MS Office 97/XP/2003 qui n'avait que très peu évolué depuis plus de 10 ans. Ce format OpenXML totalement nouveau est incompatible avec les versions précédentes de Microsoft Office.
Voici un petit tableau comparatif des deux formats de document :

	OpenDocument (ODF)	OpenXML (MS Office 2007)
Format ouvert	Oui	En partie
Basé sur le XML	Oui	Oui
Reconnu nativement par Office 2003	Non	Non
Reconnu nativement par OpenOffice 2.3	Oui	Non
Reconnu nativement par Office 2007	Non	Oui
Plug-in de conversion pour Office 2003	Oui	Oui
Plug-in de conversion pour Office 2007	Oui	Oui
Plug-in de conversion pour OpenOffice 2.3	Oui	Oui

Nous voyons donc avec ce tableau que tant OpenOffice que Microsoft Office imposent un changement du format de document et apportent comme corollaire les problématiques de compatibilité de l'existant et de format d'échange avec l'extérieur de l'organisation.
C'est une réflexion supplémentaire qui s'impose ou va s'imposer à toutes les organisations dans la mesure où quelle que soit la suite bureautique adoptée, le format de document ne sera plus le standard « de fait » .doc ou .xls.

La compatibilité des macros

On pourrait penser qu'en optant pour Office 2007, l'organisation s'exonère des questions de compatibilité des macros écrites. Il n'est est rien. Deux éléments imposent en effet une sérieuse remise en question.
La garantie de compatibilité de Microsoft ne couvre que la suite Office 2000. Comme beaucoup d'organisations sont encore restées à Office 97, elles sortent du périmètre de compatibilité.
Des changements considérables ont été apportés à la version 2007 de la suite Microsoft Office, notamment en matière de navigation et d'interface. La disparition de certaines fonctionnalités ou l'apport de modifications dans les procédures à suivre pour effectuer des actions, par exemple, peuvent donc être à l'origine d'un mauvais fonctionnement de certaines macros créées dans des versions antérieures de la suite Office.

Quel est le coût réel d'Office 2007?

Ces différentes modalités mettent en évidence des éléments qui sont souvent oubliés dans une étude d'opportunité qui se pose ou se posera pour chacune des organisations. Avec l'arrivée des nouveaux formats bureautiques, le standard de document bureautique change entraînant avec lui un choix nécessaire et une prise de décision indispensable.

AutoIt 3 - Langage de script pour administration Windows

Pierre — Tue, 30 Oct 2007 18:40:00 +0100

Après avoir vu le titre, certains lecteurs vont penser qu'il s'agit là d'un concurrent direct de KIX avec son célèbre Kixtart (http://www.kixtart.org/). Ce n'est pas tout à fait vrai, même si l'on retrouve des fonctions communes. AutoIT est un langage de programmation orienté administration Windows, sans être pour autant restreint dans cet usage. Actif, doté d'une communauté conséquente et facilement utilisable et extensible, c'est un langage amené à être de plus en plus connu et répandu.

Accès direct : http://www.autoitscript.com/autoit3/

Introduction

Traduction de la description d'AutoIt trouvée sur le site officiel :

AutoIt v3 est un langage de script inspiré du BASIC pour automatiser l'interface de Windows et l'exécution de tâches en général. Il utilise une combinaison de simulation d'appui de touches du clavier, de mouvements de souris de manipulation de fenêtre pour automatiser des tâches qu'il n'est pas possible (ou pas efficace) de réaliser avec d'autres langages (par exemple : VBScript et ses SendKeys). Il permet de générer de petits programmes, auto-contenus et fonctionnera sur toutes les versions standard de Windows, sans avoir à gérer la contrainte des libraires additionnelles.

AutoIt a été conçu au début pour le déploiement de PC pour automatiser et configurer efficacement des milliers de PC. Au fur et à mesure de l'avancement, il est devenu un langage puissant qui supporte les expressions complexes, les fonctions définies par l'utilisateur, les boucles et tout ce que des développeurs confirmés pourraient attendre.

Nous utilisons AutoIT, notamment dans le cadre d'un script de déploiement personnalisé d'OpenOffice. Ce script peut s'insérer dans un Kixtart existant ou fonctionner indépendamment à la demande ou à l'ouverture de session.

AutoIT est livré avec une version modifiée de l'éditeur de texte Scythe qui intègre la coloration syntaxique du langage et des info-bulles pour rappeler les paramètres des fonctions. Des fonctions supplémentaires permettent de compiler et lancer le programme depuis Scythe.

Programme indépendant

Un des avantages d'AutoIt est qu'il peut se déployer sous forme d'un script (.au3) ou sous forme d'un exécutable. Dans ce dernier cas, il n'aura besoin d'aucune librairie externe pour fonctionner (sauf si vous faites appel à des DLL externes, voir plus loin). Cela permet de répandre une application rapidement sans avoir à faire de programme d'installation sur tout un réseau.

Exécuter en tant que...

LA fonction la plus importante d'AutoIt est qu'il propose un jeu de fonctions permettant d'exécuter des commandes avec des droits d'adminitrateur. Quel est l'avantage ? Mettons que sur votre réseau, les utilisateurs n'ont pas le droit d'installer de nouvelles applications. En VBS, il est possible d'utiliser un « Shell.Run » pour lancer l'application d'installation et de coupler avec un « Runas » pour qu'il lance l'installeur avec un compte administrateur et par-dessus tout cela, il faut encore utiliser la commande « SendKeys » pour envoyer des touches du clavier pour composer un mot de passe. La méthode n'est ni simple, ni efficace, car les forums sont remplis de messages de gens n'arrivant pas à utiliser cette méthode. C'est souvent à la suite de ces messages que les gens se voient proposés d'utiliser AutoIt pour remédier au problème.

Comment cela marche t'il dans AutoIt ?

Lancer un programme en tant qu'administrateur se fait simplement à l'aide de deux commandes :

RunAsSet(username, domain, password, [profil])

Run (ou RunWait)(Commande)

La première permet de définir le login/mot de passe/domaine à utiliser pour toutes les commandes Run et RunWait lancées ultérieurement. La deuxième lance la commande en paramètre.

Pour réinitialiser le compte à utiliser (et ainsi revenir sur le compte de l'utilisateur qui se connecte), il suffit de lancer la commande

RunAsSet()

Librairies externes

AutoIT propose une collection de fonctions suffisamment vaste pour couvrir la plupart des besoins en administration Windows. Cependant dans certains cas, il est nécessaire de faire appel à des DLL externes. AutoIT propose de faire appel à des librairies externes à l'aide de 8 fonctions d'ouverture, d'appel et de manipulation des données.

L'exemple suivant montre comment créer une messagebox sans passer par la fonction MsgBox d'AutoIT.

$result = DllCall("user32.dll", "int", "MessageBox", "hwnd", 0, "str", "Test de messagebox", "str", "Some title", "int", 0)

Interaction avec l'environnement graphique

L'utilisation de DLL externes, dont celles de Windows, amène au point suivant : l'interaction avec l'environnement graphique, comme les fenêtres.

L'intérêt immédiat est l'automatisation de tâches répétitives, un peu à la manière de l'Applescript sous Mac OS. Un exemple est le déploiement d'une application qui n'aurait pas de package msi disponible. Le site d'AutoIT présente un exemple en automatisant l'installation de WinZip : http://www.autoitscript.com/autoit3/docs/tutorials/winzip/winzip.htm (en anglais).

Le principe est simple :

WinWaitActive("WinZip® 9.0 SR-1 Setup", "&Setup")
Send("!s")

La première commande fait attendre le programme que la fenêtre nommée "WinZip® 9.0 SR-1 Setup" apparaisse. La deuxième envoie la combinaison de touches <CTRL> + <s> pour simuler une action sur le bouton Setup de la fenêtre.

Bien entendu, ceci n'est qu'un exemple, car WinZip met à disposition un package Msi pour faciliter l'installation. Mais cela montre bien les possibilités d'AutoIT dans le domaine.

Interfaces graphiques

AutoIT permet de créer des interfaces graphiques dans le code, à la manière du langage Java. Cependant, pour faciliter la création de ces interfaces graphiques, LazyCat a créé Koda, un programme qui permet de créer des interfaces graphiques de manière graphique, à la manière d'un IDE (VB ou Java par exemple).

La plupart des contrôles habituels sont présents (boutons, étiquettes, champs de texte, combobox...). Une fois l'interface graphique terminée, Koda générera le code à insérer dans le script AutoIT.

L'interaction avec ces contrôles dans le programme est simple :

$etape = GUICtrlCreateLabel("Initialisation...", 24, 40, 470, 17) ; pour créer une étiquette

GUICtrlSetData($etape, "nouveau texte") ;le texte de l'étiquette est modifié

Fonctions orientées administration

Outre les fonctions énoncées plus haut, AutoIT offre une foule de fonctions et variables définies pour faciliter le développement de scripts d'adminstration Windows, parmi lesquelles :

Accès à la base de registre : cela se fait avec une simple commande RegRead ou RegWrite
Accès aux variables du système : @ComputerName pour le nom de l'ordinateur, @UserName pour le nom de l'utilisateur qui a ouvert la session, @WorkingDir pour le chemin du répertoire courant d'éxecution...
Fonctions de traitement de chaînes de caractères : Plus de 30 fonctions permettent de travailler avec les chaînes de caractère : recherche, découpage, conversion, les outils les plus utilisés sont présents.
Fonctions d'accès au réseau : Les fonctions commençant par TCP permettent de se connecter à des ressources réseau. De nombreuses librairies permettent de gérer ainsi certains protocoles reconnus (HTTP, FTP...)

Conclusion

Les possibilités offertes par AutoIT sont conséquentes. L'administrateur dispose ici d'un outil simple à développer, tout en restant puissant et orienté administration Windows. Le langage évolue rapidement et une communauté importante s'est créé autour, proposant un support et de nombreux scripts.

AutoIT est une solution efficace pour tout problème de déploiement d'application, administration de réseau Microsoft Windows ou autre projet de petite ou moyenne envergure.

Ressources

Site officel : http://www.autoitscript.com/autoit3/

Téléchargement direct : http://www.autoitscript.com/cgi-bin/getfile.pl?autoit3/autoit-v3-setup.exe

Dictionnaire des fonctions : http://www.autoitscript.com/autoit3/docs/functions.htm

Dictionnaire des variables d'environnement : http://www.autoitscript.com/autoit3/docs/macros.htm

Forum : http://www.autoitscript.com/forum/

Koda : http://www.autoitscript.com/forum/index.php?showtopic=32299

Pierre Wirtz - VersusMind

Vous accompagne vers la bureautique libre

http://www.versusmind.eu

Introduction au nouveau module de génération de rapport d'OpenOffice.org

Julien — Thu, 11 Oct 2007 18:37:00 +0200

Comment générer un rapport avec des images.

Présentation

Ce document est destiné aux utilisateurs d'OpenOffice 2.3.0 désirant générer des rapports comprenant des images. C'est une des nouvelles possibilités offertes par le nouveau générateur de rapports d'OpenOffice.org arrivé avec cette dernière version.

Nous allons voir comment stocker des photographies dans Base, puis comment exploiter cette base lors d'un publipostage.
Cette possibilité est disponible grâce à l'extension « sun-report-builder ».

Quelques notions initiales

L’objectif d’une base de données est le stockage structuré de données et la mise à disposition d’outils permettant d’afficher les données de manière pertinente.
Une base est constituée de Tables. Chaque Table est constituée de plusieurs champs.
La base de données est mise à jour à l'aide d'un formulaire pour ajouter, modifier ou supprimer un ou des enregistrements.

Structure de la base

Ce document s'appuie sur un exemple constitué d'une table comportant trois types de champs.

Un champ « ID » : il comportera la clé primaire puisque les bases intégrées imposent la présence d'une clé primaire dans chaque table. Cette clé est un champ qui sera l'identifiant unique de chaque enregistrement. Elle sera générée automatiquement.
Un champ « Nom »
Un champ « Photo »

Création de la base de données

Pour créer un fichier Base, utilisez le menu Fichier -> Nouveau -> Base de Données. Suivre l'assistant en laissant les paramètres par défaut. Après avoir enregistrer votre document, le fichier Base s'ouvre en mode édition.

Structure de la Base de données

Création de la table

Sous l'onglet table, lancer « Créer une table en mode ébauche ». Dans la fenêtre d'ébauche de table, insérer les trois types de champs définis auparavant.

Le champ ID est obligatoire pour identifier de manière unique chaque donnée. Son type est 'Interger' (nombre entier). Allez sur la croix verte en faisant apparaître le menu contextuel (clic droit) et choisir 'Clé primaire'. Dans les propriétés de ce champ, cocher la case « auto-valeur : oui », cela va permettre la gestion automatique de l'identifiant.
Rajoutez les deux champs restants, Nom avec un type 'Texte' et Photo avec un type 'Image'. Laissez, leurs propriétés à la valeur par défaut.
Sauvegardez la table ainsi créée, pour la voir apparaître dans la fenêtre base. Il suffit de double cliquer dessus pour remplir celle-ci.

Création d'un formulaire

Un formulaire est un document texte spécial qui a pour objectif d'afficher, de modifier ou de saisir des données dans une Base.
Dans notre cas, il va permettre l'intégration des photographies dans la table crée précédemment.
Pour ce faire, aller sur l'icône « Formulaire », puis cliquez sur « Utiliser l'assistant de création de formulaire ».

Suivez les étapes proposées par l'« Assistant Formulaire » et transférez les champs disponibles dans la zone « Champs du formulaire ». Vous constaterez que le champ « Image » n'est pas transférable à cette étape, c'est pourquoi vous aurez à l'implémenter ensuite dans le Formulaire.

Après avoir fait la première étape, passez directement à l'étape 5 où vous allez choisir un type de mise en forme de votre document (Ne pas choisir le modèle grille).
Pour finir, passez à l'étape 8 où vous allez définir un nom au formulaire et répondez « Modifier le formulaire » à la question « Comment voulez-vous procéder après la création du formulaire ».

Maintenant que le document est ouvert en mode conception, il va falloir lui placer un contrôle qui puisse accepter les photographies.
Cliquez sur « Autres contrôles » dans la barre « Contrôle de formulaire » et ajoutez au formulaire un « Contrôle picto ».
Pour que ce contrôleur puisse faire la liaison avec la base que vous venez de créer et l'image que vous lui affecterez, cliquez sur le bouton « Contrôle » situé dans la barre « Contrôle de formulaire ». Sous l'onglet « Données », choisir le « Champ de données » qui va contenir les images.

Vous pouvez sortir du mode conception en cliquant, dans la barre de contrôle de formulaire, sur le bouton « (dés)activation le mode conception ».

Utilisation du formulaire

Maintenant que votre formulaire est créé et configuré, vous allez commencer à l'utiliser celui-ci pour insérer des entrées dans la base.
Pour insérer une image dans le « contrôle picto », double cliquez dessus et choisissez l'image souhaitée et affectez lui un nom.

Refaire cette manipulation sur autant d'entrée que vous le souhaitez.
Comme votre base est créée et peuplée, utilisons la pour générer un rapport.

Génération d'un rapport

Tout d'abord, téléchargez l'extension sun-report-builder à l'adresse suivante :
http://extensions.services.openoffice.org/project/reportdesign

Après l'avoir installé, vérifiez que l'extension soit activée.

Dans la base constituée précédemment, placez vous au niveau de l'onglet rapport puis « Créer un rapport en mode ébauche... ». Cette action va démarrer l'extension.

Dans la partie droite de la fenêtre, déplacez-vous sur l'onglet « Données », pour lui affecter :

Type de contenu : Table
Contenu : nom de la table créée précédemment

Maintenant que le rapport est lié à la table contenant les images, il ne reste plus qu'à mettre en forme votre page.
Pour cela il suffit de placer les champs souhaités dans le rapport avec le bouton « Ajouter un champ »

La mise en page effectuée, lancez la génération du rapport avec l'icône « Exécuter le report ».

Crédit

Auteur : Julien CASAVECCHIA - VersusMind

Remerciement : Jean-Michel PIERRE dont le tutoriel « Insérer des images dans Base » a servi de modèle.

Des présentations OpenOffice Impress enfin fluides.

Benoît — Thu, 11 Oct 2007 16:42:00 +0200

Ne nombreux utilisateurs d'OpenOffice.org possesseurs de cartes graphiques de marque ATI l'avaient déjà constaté à leurs dépends : la fluidité des animations Impress laissait parfois à désirer sur les modèles de cette marque : il fallait même parfois supporter quelques écrans bleus ce qui était vite très énervant.
Ce problème est maintenant résolu par une petite extension DirectX développée par SUN, téléchargeable ici.

Les nouveautés de KDE 4.0

Pierre — Tue, 07 Aug 2007 15:11:00 +0200

KDE 4.0 vient de sortir en version beta 1. Cela signifie que l'ajout de nouveautés est terminé et les développeurs se concentrent maintenant sur la résolution de bugs. L'occasion de faire un point sur les nouveautés apportées par la quatrième version de KDE.

Marble est une application comparable avec Google Earth (et en partie compatible). La légèreté est un atout de cette application, car le fonctionnement reste fluide même sans accélération OpenGL. L'un des atouts est que l'application fonctionne aussi bien en stand-alone (programme indépendant dans une fenêtre qu'embarqué dans une autre application), permettant par exemple, de géolocaliser un contact de son carnet d'adresse.

Kwin, le moteur de rendu de KDE s'est vu être le centre de toutes les attentions et a vu son nombre d'effets visuels accrus, ainsi que ses performances améliorées.

Konqueror, qui faisait office, dans les version antérieures, de navigateur web ET d'explorateur de fichiers se concentrera sur la navigation Web, tandis que Dolphin se chargera de la partie exploration. L'interopérabilité entre les deux applications a d'ailleurs été accrue et les deux programmes se verront adjoindre le logiciel GwenView pour visualiser les images.

Konsole, le shell (programme de ligne de commande) de KDE a été lui aussi largement amélioré et verra ses onglets ornés d'un titre et d'une couleur pour bien distinguer les différentes sessions.

oKular, le visualisateur universel de documents, s'est vu doté d'une meilleure accessibilité, d'une meilleure prévisualisation avant impression et d'un support accru du multithreading (multi-tâches concurrentes)

KRDC, l'outil de prise en main à distance, est en cours de réécriture et supportera désormais les onglets en cas de prise en main multiple, ainsi que le stockage des mots de passe dans l'application KWallet.

KDE PIM, le projet de gestion d'informations personnelles, va recevoir dans sa version publique, des éléments de la version professionnelle. KOrganizer va bénéficier d'une vue de type diagramme de Gantt, ainsi que d'une vue de type Outlook. KMail supporte désormais le tagging des mails (mots-clés)

Plasma, l'application qui gère le bureau, a été revue et supportera désormais le javascript, les applets SuperKaramba et pourrait supporter bientôt les widgets de Mac OS X et ceux du navigateur Opera.

Source : http://www.kde.org/announcements/announce-4.0-beta1.php

OOXML : un temps de plus pour la réflexion...

Greg — Fri, 20 Jul 2007 14:37:00 +0200

La volonté de Microsoft de présenter rapidement son format OOXML devant l'ISO en vue d'une normalisation se heurte désormais à un fâcheux contretemps.

En effet, le comité technique V1, membre de l'ISO et chargé au sein de l'INCITS (International Committee for Information Technology Standards) des dossiers relatifs aux systèmes de publication et de bureautique, vient de refuser de 2 voix le passage de ce format à la mention "Approuvé, avec commentaires". Pour franchir cette étape, deux tiers des voix des 26 membres du comité V1 étaient nécessaires. Les sociétés partenaires de Microsoft représentées dans ce comité n'étaient apparemment pas suffisamment nombreuses pour atteindre le seuil fatidique des deux tiers.

Le vote du comité V1 est crucial car il conditionne largement les choix de l'INCITS, organe influençant quant à lui les décisions des Etats-Unis pour l'adoption éventuelle d'un nouveau standard ISO.

La décision des Etats-Unis, déterminante dans le cadre d'une éventuelle normalisation du format OOXML, serait donc pour le moment négative. Si le refus se confirme, le format de Microsoft devrait sans doute connaître de profonds remaniements.

Les parlements français et italien passent au libre.

Greg — Mon, 16 Jul 2007 15:23:00 +0200

Depuis la rentrée parlementaire, chaque député de l'Assemblée nationale française dispose d'un poste de travail libre. Ce projet, à l'étude depuis 2006, est motivé par une volonté d'indépendance logicielle (notamment vis-à-vis de Microsoft), de stimulation de l'économie locale et de maîtrise des coûts (les économies réalisées à long et moyen terme devraient être non négligeables).

Les 577 députés disposeront désormais sur leur poste de travail d'un système Ubuntu Linux, ainsi que de certains logiciels libres incontournables tels que Firefox, Thunderbird et OpenOffice.org 2.0.

L'exemple français fait déjà des émules. En effet, après l'Assemblée nationale française, c'est au tour des députés de la chambre italienne de passer aux logiciels libres et à l'environnement Linux. Cette migration est conséquente puisque ce ne sont pas moins de 3500 postes de travail qui sont concernés. La distribution qui sera retenue n'est en revanche pas encore connue (et pour cause, elle ne serait peut-être même pas encore choisie...).

Les migrations des parlements français et italien sont complètes et constituent deux excellentes nouvelles pour le monde du libre. Bien entendu, les députés devront prendre en main leurs nouveaux outils bureautiques. Un temps de formation sera sans doute nécessaire. Toutefois, les avantages d'une migration sont absolument incontestables :

Sécurité. Les postes de travail utilisant des logiciels libres sont bien moins victimes de tentatives d'espionnage et de consultations illicites de données que ceux fonctionnant avec des logiciels propriétaires.
Indépendance technologique. Les postes de travail des deux parlements ne seront plus dépendants d'un seul éditeur (Microsoft).
Economie. Outre le fait de participer au développement de l'économie locale, cette migration devrait permettre au parlement italien d'économiser environ 900 euros par poste de travail, ce qui représente une économie totale de 3 millions d'euros.

Enfin un vrai convertisseur vers ODF : merci SUN !

Greg — Fri, 06 Jul 2007 15:43:00 +0200

C'est aujourd'hui une bonne nouvelle pour toutes les démarches de migration vers OpenOffice.org. En effet, depuis hier, Sun propose en téléchargement gratuit un convertisseur au format standardisé ODF pour les documents Word, Excel et Powerpoint produits avec les versions de Microsoft Office allant d'Office 2000 à Office 2003 en passant par XP. Pour le moment, ce plugin ne serait toutefois pas compatible avec Office 2007.

Ce convertisseur, disponible uniquement en anglais, devrait être rapidement traduit en d'autres langues dont le français.

Ce plugin semble bien meilleur que son équivalent de Microsoft que la société de Redmond avait fait développé par la société française Cleverage. Dans Word, il permet d'ouvrir et de sauvegarder des documents texte au format ODF. Avec Excel et Powerpoint, il est désormais possible d'importer et d'exporter des feuilles de calculs et des présentations au format ODF.

Pour réaliser ce plugin, Sun a utilisé des filtres ayant été constamment améliorés avec StarOffice et OpenOffice. Ces filtres seraient apparemment bien plus performants que la technologie XSLT utilisée par Microsoft, un outil de conversion reposant sur du XML.

Le convertisseur de Sun vient directement concurrencer le traducteur Open XML / ODF pour Office 2003 et 2007 annoncé en mars dernier par le tandem Microsoft / Novell, servant essentiellement à exploiter le format OOXML de Microsoft dans la suite OpenOffice. Le plugin de Sun va bien plus loin en proposant tout simplement de récupérer les documents créés depuis 2000 avec les diverses suites bureautiques Microsoft.

La page de téléchargement du Sun ODF Plugin 1.0 for Microsoft Office

XPS : encore un standard ou un nouveau monopole ?

Greg — Wed, 04 Jul 2007 18:02:00 +0200

Après avoir fait du format Office Open XML (OOXML), utilisé dans la suite bureautique Office 2007, un standard reconnu, Microsoft souhaite désormais en faire autant avec son format de documents XPS (XML Paper Specification). Le format XPS, concurrent direct du PDF d'Adobe, vient en effet d'être soumis à l'organisme de standardisation de référence Ecma (European Computer Manufacturers Association) International . Ce dernier a crée un comité technique chargé de développer un standard basé sur le XPS dans le but de le soumettre à la validation de l'Organisation Internationale de Normalisation (ISO). La norme ISO est souvent perçue comme un gage de qualité pour les administrations publiques et les grandes entreprises. La réponse de l'ISO concernant une normalisation éventuelle du XPS ne devrait toutefois pas tomber avant 2010.

Le comité technique de l'Ecma travaillant sur la normalisation du format XPS a pour mission de "créer un format standard de document électronique basé sur le langage de description de pages XML qui soit cohérent avec les implémentations existantes du format XPS".

Par ailleurs, le format OOXML de Microsoft devrait lui aussi être soumis cette année encore au jugement de l'ISO dans l'optique d'une normalisation intégrale.

Le cas du XPS stigmatise encore davantage l'opposition entre Microsoft et le reste de l'industrie informatique. Le vice-président d'IBM Bob Sutor, chargé de l'Open Source et des standards et farouche opposant du format OOXML, n'a pas hésité à dénoncer le passage en force de Microsoft au sujet des tentatives de normalisation de XPS et d'OOXML. En effet, Sutor vient d'exprimer publiquement ses craintes en terme d'ouverture, d'indépendance et de degré de collaboration dans les prochaines années : "Devons-nous économiser notre temps et notre argent et laisser Microsoft définir les normes internationales basées sur ses propres produits ?"

Le gouvernement vénézuélien se dote de PCs sous Linux.

Greg — Wed, 27 Jun 2007 11:14:00 +0200

Le Venezuela vient d'équiper son parc informatique de systèmes d'exploitation basés sur Linux. Cette migration traduit un profond désir d'indépendance technologique du Venezuela vis-à-vis des standards étrangers.

A priori, il ne s'agirait pas que d'une simple migration. Dans les faits, le ministère de l'Industrie et du Commerce, au même titre qu'une entreprise chinoise partenaire, est actionnaire de la Venezuela de Industria Tecnologica, l'entreprise qui fabriquera les PCs. Le gouvernement projette donc de s'investir pleinement dans cette migration, en envisageant de produire localement certains des composants entrants dans la fabrication des machines.

La commercialisation des machines, habituellement assurée par des institutions privées, sera cette fois prise en charge par l'Etat. Ces PCs sous Linux seront tout d'abord destinés aux missions gouvernementales, ainsi qu'aux institutions publiques. Ils devraient par la suite être mis à disposition du grand public, participant ainsi à l'essor de Linux au Venezuela ainsi que dans l'ensemble de l'Amérique Latine.

Microsoft Office remplacé par NeoOffice dans les écoles néo-zélandaises.

Greg — Fri, 08 Jun 2007 10:05:00 +0200

En Nouvelle-Zélande, le ministre de l’Éducation a choisi de ne pas reconduire le partenariat avec Microsoft qui consistait pour les écoles du pays à utiliser principalement Microsoft Office.

La suite propriétaire devrait donc être supprimée de plus de 25 000 Mac présents dans les écoles néo-zélandaises. Les applications Word, Excel et PowerPoint seront remplacées par NeoOffice.

Cette décision devrait permettre à la Nouvelle-Zélande d'économiser près de 1,5 million d’euros.

Sortie d'Ubuntu 7.04 « Feisty Fawn ».

Greg — Fri, 20 Apr 2007 18:38:00 +0200

Ubuntu 7.04, encore appelée « Feisty Fawn », est disponible depuis le jeudi 19 avril.

Cette nouvelle version très attendue comprend plusieurs améliorations :

Configuration automatique du réseau grâce à NetworkManager.

Migration depuis Windows proposée par l'installateur (incluant la reconnaissance des favoris d'Internet Explorer et de Firefox, des fonds d'écrans, mais également la possibilité d'importer des contacts AOL et Yahoo au cours de l'installation) .

Meilleur support des applications Windows.

Gestion améliorée des applications multimédia, notamment par l'installation de Flash, de Java de Sun ainsi que de multiples codecs.

Installation facilitée des drivers pour les cartes graphiques.

VersusMind se félicite de la sortie de la version Ubuntu 7.04. Découvrez les offres de services et de formations Ubuntu proposées par VersusMind.

La nouvelle version bêta 7.04 d'Ubuntu est présentée au public.

Greg — Tue, 27 Mar 2007 09:27:00 +0200

Ubuntu Linux vient de se doter de nouveaux atouts permettant à l'utilisateur d'envisager sereinement une migration depuis Windows. En sortant sa version bêta 7.04, la distribution gagne encore en crédibilité. En effet, cette nouveauté d'Ubuntu, qui n'est qu'une version bêta pour le moment, fait déjà preuve d'une grande fiabilité.

Utilisant le noyau 2.6.20, Feisty Fawn englobe, entre autres, GNOME 2.18, OpenOffice.org 2.2.0rc3 et X.org 7.2 pour le poste de travail. Concernant les serveurs, cette version bêta dispose d'Apache 2.2, de PostgreSQL 8.2, de PHP 5.2.1 ou encore de LTSP 5.0.

La virtualisation fait également son apparition, VT chez Intel et AMD-V. Signalons également la possibilité d'importer les signets de Firefox ou d'Internet Explorer depuis une partition Windows, tout comme les contacts de messagerie de type Yahoo, MSN ou AOL.

Lors de l'installation, il est possible de sélectionner les codecs que l'on souhaite, pour visualiser des films ou écouter de la musique par exemple. Enfin, cette version bêta d'Ubuntu propose un partage réseau plug&play du nom d'AVAHI .

Avec une version bêta 7.04 présentant de telles dispositions, nous ne pouvons qu'attendre avec impatience la sortie de la version définitive...

Le Danemark s'engage avec force dans la voie des standards ouverts.

Greg — Thu, 22 Mar 2007 17:01:00 +0100

Depuis 2006, le Danemark ne cesse de manifester son intérêt pour les formats ouverts. Ainsi, le 2 juin 2006, le Parlement a voté l'utilisation obligatoire des standards ouverts dans les Technologies de l'Information et de la Communication du pays, en fixant 2008 comme date butoir. Le 23 févier 2007, Helge Sander, Ministre danois de la Science, de la Technologie et de l'Innovation, a précisé les implications concrètes de cette décision.

Le rapport met l'accent sur deux points qui risquent fort de faire débat dans les mois à venir. Ainsi, « les standards ouverts devront être implémentés graduellement en rendant obligatoire l'utilisation de ces standards ouverts pour le secteur public quand cela est techniquement possible ». Par ailleurs, les standards ouverts ne seront obligatoires que « si une étude économique montre que cela n'entraînera pas de coût supplémentaire pour le secteur public ».

Bien évidemment, les différents protagonistes de cette profonde mutation à venir se querellent déjà au sujet de la dénomination « standard ouvert » qui paraît encore bien équivoque. De même, les organisations danoises vont-elles faire preuve de suffisamment de bonne volonté pour que l'adoption de standards libres soit au final « techniquement faisable » ? Enfin, la question des coûts de migration vers les logiciels libres ainsi que de leur utilisation future constituera sans doute également un frein potentiel à la généralisation de ceux-ci dans les systèmes bureautiques du pays.

Le vote du Parlement danois constitue néanmoins une excellente nouvelle pour les défenseurs des standards ouverts !

Le ministère de la Défense poursuit dans la voie du logiciel libre

Greg — Tue, 20 Mar 2007 15:58:00 +0100

Alors que la DGME (Direction Générale de la Modernisation de l'Etat) éprouve des difficultés au niveau du RGI (Référentiel Général d'Interopérabilité), la Direction Générale des Systèmes d'Information et de Communication du ministère de la Défense manifeste, par le biais d'une première directive, sa volonté d'utiliser toujours davantage de logiciels libres.

Dans cette directive, deux points majeurs sont à souligner, à savoir un recours officiellement affiché aux standards ouverts ainsi qu'une préférence pour les logiciels libres à coût, risques et efficacité comparables.

Par cette directive, le ministère de la Défense semble progressivement suivre dans son ensemble l'exemple donné par l'une de ses composantes majeures : la Gendarmerie Nationale.

La DGME compte désormais un ministère incontournable dans ses rangs, ce qui pourrait permettre d'engager le RGI sur la voie des standards ouverts et des logiciels libres.

L'Etat se penche sur le coût et sur l'efficacité de ses équipements informatiques.

Greg — Fri, 16 Mar 2007 11:57:00 +0100

Une étude datant de 2003 et portant sur les coûts moyens d'un poste de travail avait abouti à la conclusion suivante : la part consacrée au support et aux services d'infrastructures représentait 50 % du coût total alors que celle dédiée à l'acquisition et à la maintenance du matériel en représentait 16 %. L'Etat dispose d'un parc informatique considérable et pourrait réaliser des économies de plusieurs centaines de millions d'euros, à condition d'optimiser ses équipements bureautiques.

Toutefois, le nombre de systèmes d'information différents actuellement installés sur les postes de travail de l'Etat est si important qu'il est quasiment impossible de procéder à une optimisation informatique pertinente en terme de réduction de coûts, mais également de cohérence, de compatibilité et d'efficacité.

L'Etat vient d'engager une phase d'audit de son parc informatique, regroupant sous cette appelation le matériel informatique de bureautique (à l'exception de matériels bureautiques métiers de type industriels liés à des systèmes particuliers), les logiciels des postes de travail, ainsi que l'ensemble des ressources humaines du secteur informatique.

Les objectifs avoués sont une meilleure visibilité du parc bureautique de l'Etat sur les plans organisationnel et technique, l'élaboration d'un tableau de bord destiné à améliorer l'efficacité des équipements tout en réduisant les coûts ainsi que l'implication véritable des différents ministères dans l'optimisation de la bureautique étatique.

Les logiciels libres utilisables en toute légalité dans les marchés publics.

Greg — Mon, 05 Mar 2007 14:19:00 +0100

Lors du dernier salon Solutions Linux, le droit d'utilisation des logiciels libres dans l'administration a été clairement précisé par Marie José Palasz, chef de service à la Direction des Affaires Juridiques du Ministère de l'économie et des finances.

Ainsi, les marché publics sont autorisés à utiliser les logiciels libres dont les contrats ont été précisément définis au préalable. Par conséquent, les tentatives de SCO et Microsoft visant à discréditer les logiciels libres d'un point de vue juridique n'ont aucun fondement légal.

En revanche, l'insécurité juridique liée aux brevets logiciels est quant à elle bien réelle. Microsoft vient d'ailleurs d'être condamné à verser 1,5 milliard de dollars à Alcatel-Lucent pour violation de brevets concernant le format de compression mp3.

Cuba confirme sa préférence pour le libre.

Greg — Mon, 05 Mar 2007 14:16:00 +0100

A la Havane, le gouvernement cubain a annoncé sa volonté de migrer plusieurs milliers de PC vers GNU/Linux. Ceux-ci viendront s'ajouter aux 1500 postes informatiques Linux déjà existants depuis 2005. Cette nouvelle intervient quelques semaines après la sortie de Windows Vista de Microsoft.

Certes, le choix des autorités cubaines pour le logiciel libre semble avant tout guidé par la volonté de sortir le pays du marasme économique par l'essor technologique. Toutefois, il est difficile de ne pas y voir également une contestation de la toute-puissance américaine incarnée par Microsoft.

Cuba confirme ainsi la préférence affichée des pays d'Amérique Centrale et du Sud pour le libre.