Debug Series - Les sources Java Alfresco

Introduction

Le saviez-vous : Alfresco peut être débuggué comme n’importe quelle application Java.

Ce dont vous avez besoin :

- Une instance d’Alfresco sur votre poste

- Un environnement de développement

- Le code source d’Alfresco (de la même version que votre instance)

Dans l’exemple que je vais suivre ici, j’utilise Alfresco Community 4.0a (dans un serveur tomcat, sur environnement Windows), l’environnement de développement Eclipse, au sein duquel j’ai importé les sources d’Alfresco community 4.0a.

Pour le téléchargement des sources d’Alfresco, vous pouvez visiter ces quelques liens :

http://wiki.alfresco.com/wiki/Alfresco_SVN_Development_Environment

http://wiki.alfresco.com/wiki/Source_Code

http://wiki.alfresco.com/wiki/Alfresco_on_Eclipse

Configuration

Notre objectif est de pouvoir debugguer Alfresco, en plaçant des points d’arrêt dans le code, en observant la valeur des variables à un instant t, etc …

Pour ce faire, il faut réaliser quelques configurations.

1/ Tout d’abord, en lisant la page suivante de la doc d’Apache tomcat :

http://wiki.apache.org/tomcat/FAQ/Developing

Il faut donc, dans votre installation d’Alfresco, modifier le fichier alfresco.bat pour ajouter, à la fin de la ligne « set JAVA_OPTS= » :

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

On a ainsi configuré le serveur d’application pour qu’il « écoute » un éventuel debugger sur le port 8000.

2/ Alfresco étant lancé, on peut « activer » le debugger d’Eclipse.

Dans Eclipse, ouvrir le menu « Run/Debug configurations ». Sélectionner « Remote Java Application », puis cliquer sur le bouton en haut à gauche « New Launch configuration ».

Alors, dans le volet de droite, il faut configurer cette nouvelle configuration de Debug. A minima, voici ce dont il faut s’assurer :

- Donner un nom à la configuration

- Onglet « connect » / Vous pouvez laisser les paramètres de connextion par défaut (hôte : localhost, port : 8000)

- Onglet « source » / ajoutez l’ensemble des projets source Alfresco

- Onglet « common » : vous pouvez laisser les valeurs par défaut

(Bien sûr, avec un peu d’expérience, vous pourrez modifier l’ensemble des champs.)

Enfin, cliquez sur sur le bouton « debug », en bas de la fenêtre de configuration.

Debug Mode

Alors, une nouvelle « perspective » dans Eclipse s’ouvre : c’est la vue Debug.

Elle vous permet d’ouvrir des classes, d’y placer des points d’arrêt, de définir des variables pour en observer la valeur à un instant t, etc … comme pour toute application Java !

Conseils pour la découverte de Solr avec Alfresco

Pour ceux qui s'apprêteraient à essayer l'intégration Solr dans Alfresco (en préparation de la sortie de la version 4.0), voici quelques conseils et ressources :

Lire tout d'abord :

• http://docs.alfresco.com/4.0/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Fconcepts%2Fsolr-intro.html
• http://wiki.alfresco.com/wiki/Alfresco_And_SOLR
• http://www.slideshare.net/alfresco/understanding-the-solr-integration

Une fois les concepts de base appréhendés, il peut être intéressant par exemple de dumper le traffic HTTP entre un repository et Solr, pour avoir quelques exemples de requête effectuées et mieux comprendre l'interaction entre les deux.

Exemple de requête sur le mot "test" effectué depuis Share :


 (test) AND -TYPE:"cm:thumbnail" AND -TYPE:"cm:failedThumbnail" 
        AND - TYPE:"cm:rating"

Pour analyser les résultats, cette requête peut également être exécutée sur l'interface d'admin Solr.

Cette interface d'admin permet de mieux comprendre le fonctionnement interne de Solr, et est fournie avec le war solr et accessible à l'addresse suivante :  http://localhost:8080/solr/

Des  pages d'admin sont disponibles par "core" Solr, par défaut une pour "alfresco" correspondant à workspace/SpacesStore et une pour archive/SpacesStore. La documentation de cette interface est disponible ici : http://wiki.apache.org/solr/SolrAdminGUI

Des options de recherche avancée permettent de sélectionner des options supplémentaires telles que les champs à retourner, le nombre de résultats, le type de sortie (xml, json, ...)... Des options permettent également de demander la sortie "debug", c'est à dire la sortie incluant l'explain sur la requête, et les temps d'exécution des differentes étapes : parsing, filtrage, etc ..

Un point qui n'est pas sélectionnable dans l'interface d'admin actuellement est le query parser. Il en existe 4 par défaut : "alfresco" (AlfrescoLuceneQParserPlugin), "afts" (AlfrescoFTSQParserPlugin) et "cmis" (CmisQParserPlugin), ainsi que "select" (le parseur Solr/Lucene par défaut).

Voir http://www.slideshare.net/alfresco/moving-from-lucene-to-alfresco-fts pour plus d'informations sur le parseur FTS.

Pour chaque node à indexer côté repository, 2 nodes sont indexées dans Solr/Lucene :

- le node "LEAF", contenant le type, les aspects, et les identifiants du node. C'est celui qui est retourné lorsque l'on utilise les parseurs alfresco ou afts

- le node "AUX" (auxiliaire) contenant les informations "auxiliares" du node, à savoir ses parents, son path, le owner, les éventuelles ACL indexées, ainsi que les identifiants également.

Il y a donc dans ce cas deux documents au sens Lucene correspondant à un node indexé par Alfresco.
Ressources supplémentaires :

http://www.slideshare.net/teofili/apache-solr-crash-course http://lucidworks.lucidimagination.com/display/solr/Apache+Solr+Reference+Guide
http://wiki.apache.org/solr/SolrAdminGUI

Facilitez vos développements Alfresco Share avec Surfbug

Un commentaire qui revient de temps en temps est qu'il n'est pas simple d'étendre des composants Alfresco Share ou de s'inspirer d'existants pour en créer des nouveaux.

Surfbug est là pour répondre à ce besoin. Disponible depuis la version 3.4.3 (et +), il permet par simple clic d'afficher toutes les informations relatives à un composant : son URL, sa définition, les templates le constituant, et la localisation dans le classpath des fichiers qui le composent. 

Il s'active via la page http://localhost:8080/share/page/surfBugStatus . Cet accès est restreint aux administrateurs, car l'activation est globale pour tous les utilisateurs. Il faut donc l'utiliser comme un outil de développpement. 

Son utilisation est très simple : Des rectangles rouges démarquent les différents composants. il suffit, après l'avoir activé, de cliquer sur un composant pour lequel on souhaite connaître les détails. 

Voici un exemple : 

Plus d'informations disponibles ici : http://blogs.alfresco.com/wp/ddraper/2011/08/31/surfbug/

Collaborez efficacement avec les règles de contenu

L’une des fonctionnalités phares d’Alfresco (depuis plusieurs versions), et qui est mise en œuvre dans la vaste majorité des projets est la gestion des règles de contenu (content rules).
Les règles de contenu permettent d’ajouter de « l’intelligence » à vos répertoires / dossiers / espaces, d’une manière comparable aux filtres que vous pouvez définir pour votre messagerie email.

En effet, beaucoup d’entre nous ont configuré la messagerie professionnelle pour y organiser quelque peu la quantité d’emails reçus chaque jour. Par exemple, dans mon cas, j’ai créé différents dossiers, et les règles de filtre suivantes :
- Pour tout mail où je suis en copie (CC), le placer dans le dossier « à traiter
plus tard (cc) »
- Pour tout mail contenant les mots « Projet YYYYYY », le placer dans le dossier « Projet YYYYYY »
- Etc …

Ainsi, Alfresco vous propose une fonction tout-à-fait similaire : les règles de contenu, qui permettent d’automatiser certains traitements dans votre GED.
Une règle se caractérise par plusieurs éléments :
- « Ou ? » => Dans quel dossier (ou dans quelle arborescence) du plan de classement la règle doit-elle être effective
- « Quand ? » => Quel évènement doit déclencher l’exécution de l’action automatique ?
- « Quoi ? » => Quelle est l’action à effectuer ?

Puisque rien n’est plus explicite qu’un exemple bien choisi, nous allons montrer comment, en quelques minutes, les règles de contenu de votre GED Alfresco peuvent drastiquement améliorer la tâche d’une équipe Marketing.

Le contexte fictif :

L’équipe Marketing de l’entreprise ACME collabore, au sein d’Alfresco, autour de différents documents. Certains de ces documents doivent être validés par un directeur, avant de pouvoir être publiés à l’extérieur sur les réseaux sociaux. Par ailleurs, seul le Social Marketing Manager doit avoir la capacité de publier sur les réseaux sociaux, la version PDF des documents validés.

Au final, nous verrons que :

- les collaborateurs marketing utilisent Alfresco pour piloter la création de documents

- le Managing Director, très occupé, n’a qu’à consulter une « corbeille » pour consulter en un coup d’œil les documents soumis à son approbation

- le Social Marketing Manager, de la même manière, n’à qu’à consulter une « corbeille » pour voir la liste des documents déjà validés, et prêt à être publiés sur les réseaux sociaux.

Mise en place dans Alfresco :

Voici comment l’on peut mettre en œuvre ce besoin, dans Alfresco, notamment à l’aide des règles de contenus. Je ne couvrirai pas en détails chaque étape (création du plan de classement, configuration des droits, etc …), mais si un point vous échappe, n’hésitez pas à poser votre question en commentaire !

1/ Création du site, invitation des utilisateurs

Je crée donc un espace collaboratif (site) intitulé « Marketing » que je paramètre selon mes besoins, et j’y invite des utilisateurs auxquels je confie des rôles.

Notons sur l’exemple qu’Alice Beecher est la Social Marketing Manager, et Mike Jackson le Marketing Director.

2/ Création du plan de classement, gestion des droits sur les espaces

Je crée l’arborescence dont l’équipe marketing a besoin, et je configure correctement les droits sur chaque espace.

Dans notre exemple, les collaborateurs peuvent travailler sur les documents dans Projets 2011 / Documents en cours.

L’espace Projets 2011 / Valider pour diffusion permet au Marketing Director de consulter les documents soumis, pour lui permettre de les valider ou de les refuser.

L’arborescence Communication externe / Réseaux sociaux (Social Manager) / … est réservée au Social Marketing Manager pour publier les documents.

3/ La règle de contenu de transformation en PDF

Nous allons définir la règle suivante :

« dés qu’un document est déposé dans l’espace ‘Valider pour diffusion’, il faut alors automatiquement le transformer en PDF »

Pour cela, nous créons une nouvelle règle de contenu sur l’espace « Valider pour diffusion » (via l’icône du bouton d’action correspondant) :

- nous lui attribuons un titre, comme « Transfo PDF », et éventuellement une description

- nous choisissons l’évènement déclencheur de la règle qui est « Des éléments sont créés ou entrent dans ce dossier »

- nous ne filtrons pas davantage la condition de déclenchement (en laissant la valeur « tous les éléments »)

- nous choisissons l’action « transformer et copier le contenu », TYPE MIME « Adobe PDF », vers « Valider pour diffusion »

4/ La règle de contenu d’association des PDF à un « workflow simple d’approbation / refus »

Nous allons définir la règle suivante :

« dés qu’un document de type PDF est créé dans l’espace ‘Valider pour diffusion’, il faut alors automatiquement lui apposer un workflow simple d’approbation :

- en cas de validation, déplacer le document dans ‘Documents Validés – à publier sur SlideShare’

- en cas de refus, déplacer le document dans ‘Documents refusés’ »

Pour cela, nous créons une nouvelle règle de contenu sur l’espace « Valider pour diffusion » (via l’icône du bouton d’action correspondant) :

- nous lui attribuons un titre, comme « Workflow Simple », et éventuellement une description

- nous choisissons l’évènement déclencheur de la règle qui est « Des éléments sont créés ou entrent dans ce dossier »

- nous filtrons pour ne sélectionner que les documents dont le type-mime est « Adobe PDF »

- nous choisissons l’action « associer à un workflow simple ». En cas d’approbation, nous choisissons de « déplacer » le contenu vers l’espace « Documents Validés – à publier sur SlideShare », en cas de refus nous choisissons de « déplacer » le contenu vers l’espace « Documents refusés »

Testons notre cas d’usage :

1/ Avec un utilisateur quelconque, déposons un document Word « test_word.doc » dans l’espace « Valider pour diffusion » (la règle de contenu se déclenche alors)

2/ Connectons-nous à Alfresco en tant que Mike Jackson (Marketing Director), et ouvrons l’espace « Valider pour diffusion ».

Nous voyons alors dans cet espace une copie PDF du document déposé « test_word.pdf ». Et, parmi la liste des actions associées à ce fichier PDF, nous constatons que 2 nouvelles actions sont disponibles « Approuver » et « Rejeter ». C’est la règle de contenu qui, en associant automatiquement un workflow simple au nouveau document PDF, permet de disposer de ces actions.

3/ Cliquer sur l’action « Approuver ». Le document disparait alors de l’espace de validation, et est déplacé automatiquement vers l’espace ‘Documents validés – à publier sur SlideShare’ dédié à notre Social Marketing Manager.

4/ Connectez-vous à Alfresco en tant qu’Alice Beecher, et consulter l’espace ‘Documents validés – à publier sur SlideShare’, vous voyez apparaitre le document PDF précédemment validé par Mike Jackson.

Vous pouvez alors le publier sur les réseaux sociaux !

Conclusion :

Nous n’avons vu ici le principe de fonctionnement des règles de contenus, qui dans ce cas nous ont permis de déployer une procédure de validation simple en quelques minutes.

Mais, en testant par vous-même, vous pourrez constater que les règles de contenus sont riches :

- sur les filtres de déclenchement : n’exécuter la règle que pour tel type de documents/espaces, selon le nom de l’auteur, le mime-type, la taille du fichier etc …

- sur les actions à exécuter : déplacer automatiquement, transformer en PDF, apposer une catégorie, etc …

Elles peuvent même être étendues en déclenchant des scripts personnalisés !

Alfresco 4 : publication réseaux sociaux

La nouvelle version Alfresco 4 Community est déjà parue depuis quelques semaines, mais vous n’avez sans doute pas eu le temps d’en explorer chaque nouveauté.

L’une des nouvelles fonctionnalités les plus séduisantes pour les équipes de communication et marketing est la « publication sur les médias sociaux ». Voici en quoi ça consiste concrètement :

- Paramétrer dans Alfresco un ou plusieurs comptes (channels) associés aux réseaux sociaux (services) FlickR, Twitter, Facebook, Youtube, Linkedin, et potentiellement d’autres …

- Administrer les utilisateurs ou groupes d’utilisateurs Alfresco habilités à publier sur chacun de ces canaux

- Publier du contenu (documents, images, vidéos …) sur les réseaux sociaux via l’interface Alfresco Share

- Publier simultanément sur plusieurs réseaux sociaux (exemple : publier une image sur FlickR, et publier un message avec un lien vers l’image FlickR sur twitter et linkedin)

On a ainsi la capacité de centraliser, sur une plateforme de gestion de contenus, l'ensemble des documents publiés sur les réseaux sociaux et de les administrer (consulter les versions publiées, les mettre à jour, etc ...)

Créer les comptes (channels) :

La première étape pour tester ces fonctionnalités de publication sociale consiste à créer les social channels. Cela est possible via la console d’administration (dans l’interface Alfresco Share), en étant donc connecté en tant qu’administrateur.

Il faut alors naviguer dans la rubrique « gestion des canaux ». Vous notez alors que vous pouvez créer un ou plusieurs « canaux » de type différents, voire du même type (dans l’exemple sur le screenshot, un compte twitter « ACME Corp », et un compte twitter « ACME Corp Events »). Lors de la création d’un nouveau canal social, une popup s’ouvre pour vérifier l’authenticité du compte associé au réseau social (par login / mot de passe).

Les trois liens sous chaque canal permettent :

- De paramétrer les droits des utilisateurs Alfresco de publier sur le canal

- De (re)valider l’authentification au compte sur le média social

- De supprimer définitivement le canal

Configurer les droits des utilisateurs :

Ainsi, en cliquant sur le lien « permissions », l’administrateur peut décider quels utilisateurs ou groupes d’utilisateurs auront la capacité de publier sur le canal.

Dans l’exemple du screenshot, nous configurons que seule l’utilisateur « Alice Beecher », Social Communication Manager » pourra gérer les publications sociales. On lui donne un rôle de « coordinator » sur l’ensemble des canaux.

Publier :

Alors, l’utilisateur Alice Beecher peut se connecter à Alfresco, et naviguer jusqu’au document qu’elle souhaite publier.

A noter, dans la version que je teste actuellement, il est nécessaire de disposer au moins d'un channel Twitter (même si je souhaite ici publier une image sur FlickR), afin de publier un message court.

En cliquant sur « publier » (dans la liste des actions d’un document), une popup s’ouvre et permet de choisir :

- Le canal de publication du contenu

- Aucun, un ou plusieurs autres canaux sur lesquels publier un message (twitter, linkedin par exemple)

- Afficher ou non, dans ce message, un lien vers le contenu publié

Superviser :

Enfin, un coup d’œil rapide à la page de détails des documents dans Alfresco Share permet de visualiser les informations de publication (échec / succès, date de la publication). Il est même possible, pour les canaux sociaux qui le permettent, de supprimer une publication !

Services de transfert et réplication

Les services de Transfert et de réplication sont apparus respectivement en version 3.3 et 3.4 d'Alfresco. Ces services ont pour but l'envoi et la réception d'information d'un repository Alfresco à un autre. Cet article est un résumé des fonctionnalités offertes par ces deux services.

1. Transfer Service

Tout d'abord, quelques généralités sur le Transfer Service, apparu en version 3.3. Il Permet de pousser des noeuds d'un repository à un autre. Sans rentrer dans les détails d'implémentation, les propriétés des noeuds transférées sont envoyées séparément des contenus binaires associés à ces noeuds, ces derniers étant groupés pour minimiser les aller/retours entre les entrepôts.

Un cas d'utilisation classique : une entreprise dont le siège transfère des portions d'arborescence a des entrepôts Alfresco situés dans des filiales géographiquement distantes, pour leur fournir un accès localisé et donc plus rapide aux contenus les concernant. Quelques points à noter sur ce service :

• Les transferts peuvent utiliser HTTP ou HTTPS
• sur le repository cible, les noeuds de destination sont "enrichis" par des aspects (ex trx:transferred) afin de conserver la provenance des noeuds transferés
• Les transferts donnent lieu à l'écriture de rapports XML sur la source et sur la cible, faisant état du statut du transfert, ainsi que référençant, entre autre, les différents noeuds transferés
• Transferts synchrones ou asynchrones
• Attention : le transfert doit se faire à modèle de données équivalent : on ne peut transférer des noeuds possédant par exemple un aspect qui n'est pas défini sur le repository cible
• Permet le transfert chainé. Voir graphique ci-dessous :

Un transfert donné nécessite la définition de :

• transfer targets (nodes possédant des métadonnées décrivant les identifiants de connexion, l'url , le port, ... du repository de destination). La création de celles-ci se fait en créant un folder dans le dossier "Transferts/Groupes de cibles de transfert/Groupe par défaut" du Dictionnaire de données

• transfer definitions ( les nodes qui doivent être transférés). Le transfer service ne possède pas d'UI pour sélectionner des nodes, mais une API assez riche permettant de sélectionner/filtrer des nodes en fonction de différents critères (voir les interfaces NodeCrawler, NodeFilter, NodeFinder). Le replication service (voir ci-dessous) possède quant à lui une UI associée.

2. Replication Service

Ce service est apparu en version 3.4. Il s'appuie sur le transfer service décrit ci-dessus. Quelques points à noter sur ce service :

• S'ajoute aux cibles (ou ?) et définition de transfert (quoi ?), les "travaux de réplication (replication jobs) (quand ?). Ceux-ci permettent de définir un planning de réplication (ou bien de les déclencher à la demande). Un suivi graphique des travaux, ainsi que des rapports en fin de job sont également disponibles.
• Une page de la console d'administration permet de gérer, programmer, déclencher et suivre, et annuler ces jobs. Celle-ci s'appuie sur l'API ReST exposée par le replication service. Celle-ci est implémentée par des Web Scripts écrits en Java.

• A noter : les noeuds transférés sont par défaut en lecture seule, car il n'y a pas de synchronisation bidirectionnelle. Le mode lecture seule ou non est toutefois configurable dans les propriétés du subsystem de Replication (propriété replication.transfer.readonly).

3. A venir

Diverses améliorations sur ces services sont envisagées. Voir les liens ci-dessous pour les évolutions. La prochaine version d'Alfresco, prévue pour la fin de l'année, devrait notamment permettre de transférer du contenu vers un filesystem physique, plutôt qu'exclusivement vers

d'autres entrepôts Alfresco.

4. Liens

Pour plus de détails sur ces deux services, consultez les pages wiki suivantes :

• http://wiki.alfresco.com/wiki/Transfer_Service
• http://wiki.alfresco.com/wiki/Replication_Service
• http://wiki.alfresco.com/wiki/Replication_REST_API

Tutoriel Dashlet spécifique People Statuses (1/3)

Cet article constitue le premier élément d'une série de quelques tutoriaux sur le développement spécifique sous l'interface Alfresco Share.

Nous avions déjà abordé, sur ce blog, les fondamentaux à travers la conception de dashlets très simplistes "Hello World".
Ici, il s'agit d'aller une étape plus loin, en créant un "vrai" nouveau dashlet un peu plus utile qu'un simple "Hello World". L'objectif est de créer un dashlet qui affiche la liste des statuts des utilisateurs.

Pourquoi ce tutorial ?

Je sais qu’il peut être difficile de se lancer dans le développement spécifique sur l’interface Share, ce fut d’ailleurs mon cas. En effet, les premières barrières que j’ai rencontrées sont :
1/ Les patterns de conception : j’avais plutôt une bonne expérience du développement de webscripts Alfresco, mais j’avais du mal avec leur implémentation dans l’interface Share
2/ Le développement sous YUI

Ainsi, ce tutorial vise simplement à vous permettre de mettre un pied dans le développement spécifique Share. Bien sûr, si vous ne maitrisez aucunement YUI (ce qui était mon cas), ce sera toujours un peu difficile, il faudra lourdement s’appuyer sur la doc officielle, et procéder à tâtons. Néanmoins, vous allez voir que le degré de complexité du développement de ce dashlet spécifique est vraiment minimal …

Le tutoriel en lui-même figure dans le fichier PDF attaché, et le code source dans l'archive zip.

N'hésitez pas à nous faire des retours sur le contenu de l'article, ou sur le code source lui-même !


Ressources :

Pour accéder directement au document, c'est ici :
Voir le document dans Google docs

Pour accèder au code source:
Voir le code source dans Google docs

Notez que vous pouvez télécharger le document PDF et le code source dans Google docs en cliquant sur le menu "Fichier", puis "Télécharger l'original"

Catégories et Tags

S’il est un besoin inhérent à toute mise en place d’un projet GED / ECM, c’est bien la classification des différents contenus (documents, répertoires, discussions, etc …).
Alfresco propose différents outils de « classification » :
- Le plan de classement
- Les métadonnées
- Les catégories
- Les tags

Le plan de classement et les métadonnées sont des concepts plutôt bien connus.

Le premier désigne l’arborescence de dossiers et sous-dossiers dans laquelle on peut archiver les contenus, permettant une navigation que l’on pourrait qualifier de « hiérarchique » ou « verticale ». C’est la navigation intuitive à laquelle on est habitué lorsqu’on utilise un ordinateur personnel, recherchant et déplaçant les fichiers entre les différents répertoires.

Les métadonnées sont parfois décrites comme une « fiche d’informations » d’un contenu. Elles sont en effet un ensemble d’informations décrivant un contenu, comme « l’auteur », la « date de modification », ou encore le « statut ».

Cependant, les concepts de catégories et de tags sont parfois moins bien compris.
Certes, dans les deux cas, il s’agit de la possibilité d’accoler une ou plusieurs « étiquettes » (ou encore « mots-clés ») à un objet (document, espace, feuille wiki, réponse à une discussion, etc …). En outre, tags et catégories permettent aux utilisateurs de naviguer au sein de l’entrepôt de manière « sémantique ».

Les catégories

Les catégories forment un vocabulaire hiérarchique de mots-clés, et défini par un administrateur fonctionnel. Elles permettent de classifier les contenus selon une taxinomie. Elles sont très utilisées notamment dans les projets d’archivage ou de « gestion de documents référentiels ».
Dans Alfresco, un contenu peut « recevoir » une ou plusieurs catégories (s’il dispose de l’aspect « Catégorisable »). Enfin, un filtre de navigation « Catégories » permet d’afficher les contenus étiquetés avec la catégorie sélectionnée.















Les tags

A l’inverse des catégories, les tags sont des mots-clés non-organisés, qui sont librement créés par les utilisateurs finaux. Les tags permettent de classifier les contenus selon une folksonomie.
Les tags sont régulièrement mis en oeuvre dans les projets collaboratifs, et les projets de capitalisation de connaissance (KM).
En effet, les tags ont l’avantage de recueillir un investissement important des utilisateurs, ceux-ci ressentant parfois une certaine frustration face au système plus rigide des catégories figées.

Dans Alfresco, tout contenu peut « recevoir » un ou plusieurs tags, déjà existants dans l’application, ou nouvellement créés à la saisie. Enfin, un filtre de navigation « Tags » permet d’afficher les contenus étiquetés avec le tag sélectionné.

On remarque également qu’une sorte de « loi darwinienne » s’applique dans l’affichage des tags dans cette entrée de navigation. En effet, les tags sont triés par ordre d’utilisation (le nombre entre parenthèses indique d’ailleurs le nombre de contenus associés au tag).
Cet ordonnancement naturel permet de pallier naturellement à l’éventuel problème de profusion de tags obscurs, mal orthographiés, ou encore inutiles.














Si vous avez des retours sur cet article, n'hésitez pas à nous en faire part !

Espace racine des protocoles FTP, CIFS ...

Vous savez sans doute déjà que l’entrepôt Alfresco est accessible par différents protocoles, notamment FTP, CIFS, NFS …

Mais savez-vous qu’il est possible de n’exposer qu’une partie de votre entrepôt via ces interfaces d’accès ?

Pour cela, il vous faut surcharger la configuration par défaut du subsystem File Servers.

Qu’est ce qu’un subsystem ? Réponse ici.

Comment configurer un subsystem ? Réponse là.

Quelques infos supplémentaires sur le FileServer Subsystem ? Voici la page wiki dédiée.

En l’occurrence, dans le cas décrit ici, il faudra adopter la 3^ème méthode de configuration du subsystem, puisque l’on va devoir modifier la définition d’un bean Spring appelé « filesystemsContext ».

En effet, il suffit de modifier la valeur de la propriété "rootPath", comme suit :

<property name="rootPath">

<!-- <value>/${spaces.company_home.childname}</value> -->

<value>/app:company_home/st:sites</value>

</property>

Dans cet exemple, nous décidons de configurer la racine des accès des interfaces de type « File Server » comme « Accueil / Sites ». Ainsi, tout utilisateur se connectant en FTP, CIFS ou NFS à l’entrepôt ne pourra voir que la liste des sites collaboratifs.

Enfin, sachez qu’en observant de près les 2 fichiers de configuration du subsystem FileServers, vous découvrirez sans doute d’autre astuces de configuration (changer le nom de l’espace racine, modifier uniquement le répertoire racine pour FTP, …)