limites de collaboration explorer et share

[felie]

Certaines fonctionnalités intéressantes ne semblant  pas disponibles sous share, je passe de temps en temps sous l'interface explorer (http://.../alfresco) pour les utiliser. Cela semble parfois poser problème.
Par exemple, si l'on supprime un message de discussion via l'explorer, cela semble rendre la file de discussion sous share totalement instable.
Avez-vous une idée des limites de l'exploitation conjointe de l'explore et share sur les mêmes documents ?

  F.

OS: debian 5.0
openOffice : 3.1.0-11
swftools : 0.9.0
Mysql : 5.0.51a-24+lenny1
jdk : sun-java6-jdk, version 6-12-1
Alfresco version: 3.2.0 (2039)
pack français : alfresco_3.2_FR.zip

[michaelh]

En résumé :

- Créer ou modifier un contenu dans Share depuis Explorer est une très mauvaise idée (en faisant ça vous zappez des étapes essentielles).
- La gestion des droits depuis Explorer est aussi une mauvaise idée (même cause).
- L'application de règles de gestion reste possible par contre.

Bref, on exploite pas un contenu Share depuis Explorer (il y a un avertissement à ce sujet, il est justifié).

[felie]

Il serait bon de comprendre quelques sont ces "étapes essentielles" sous Share qui vont à l'encontre de l'utilisation d'Explorer pour la gestion du contenu, ainsi que la différence entre "gestion des droits" et "règles de gestion".

Jusqu'à maintenant, je passais par Explorer pour définir avec précision les règles d'accès aux répertoires documents. Je créais des groupes d'utilisateurs sous Explorer et désactivait parfois l'héritage lorsque l'accès à un sous répertoires était spécifique.

La gestion des droits sous Share paraît très restrictive car on ne peut demander à un responsable de projet de penser l'arborescence des répertoires de share suivant une logique basée sur 4 rôles pour un site (ou projet).
Prenons par exemple le cas d'un bloc électronique composée de plusieurs modules, chaque module étant réalisé par des groupes de travail différents qui ne doivent pas avoir les mêmes droits (ou rôles) suivant les répertoires ou sous répertoires. La solution qui consiste à créer autant de sites que de cas de figures de rôles n'est pas viable.

Nous sommes actuellement en phase alpha du développement de la structure collaborative d'un projet. Pour le moment, je n'ai pas rencontré du problèmes de gestion via Explorer des droits d'accès au document sous share. Ceci dit, cela m'intéresserait beaucoup de comprendre les limites avant le passage à la beta. Quelqu'un a t'il un exemple de blocage à communiquer ?

[michaelh]

Je vais essayer de faire synthétique car l'histoire complète prendrait facilement une petite heure

- Tout ce qui est géré dans la partie documentaire SAUF les éléments stockés dans la portion "Share" et la portion "WCM" sont gérés dans un entrepôt qui est l'entrepôt historique (son petit nom, c'est "ADM").
- Tout ce qui est géré dans les parties WCM et Share est stockés dans un autre type d'entrepôt appelé "AVM".

ADM et AVM apparaissent de la même manière dans l'interface, mais ils ont des logiques de fonctionnement différentes à très bas niveau. Pour l'utilisateur c'est presque transparent parce que les différences d'utilisation et différentes capacités sont masquées par le système.

Pour un petit topo sur la question, voir http://wiki.alfresco.com/wiki/WCM_Overview#What_is_the_AVM.3F

Quand vous créez un contenu ou modifiez les droits, l'interface utilisée fait appel à un ensemble d'API qui vont retranscrire vos choix de configuration en fonction des capacités de l'entrepôt correspondant. Si vous placer des droits depuis Share et regardez depuis l'interface Explorer, vous verrez que la logique diffère légèrement de ce qui arrive quand on les place depuis Explorer directement. L'inverse fait que si vous placez des droits depuis Explorer, il est très possible que Share se répande en messages d'erreur parce qu'il n'était pas prévu par les concepteurs de se retrouver avec un accès interdit quelque part

Ça, c'était pour la technique.

Ensuite il y a des choix délibérés d'implémentation :  comme la simplification de la gestion de droits coté Share.

La raison de la simplification est qu'on parle de collaboratif, par d'un système verrouillé. Si on désire placer des droits complexe, alors ce n'est pas de collaboratif dont on a besoin … A titre personnel je ne vois pas non plus ce qu'apporte un site dit collaboratif dans lequel la gestion des droits devient insurmontable après 6 mois à faire des modifications sur chaque élément de contenu (toujours se demander si c'est viable à long terme).

Le choix actuel est de dire : droits différents, sites différents. Ça changera peut être, mais les statistiques chez les utilisateurs montrent que ça colle au besoin (de loin) le plus souvent exprimé pour le moment. Sinon on utilise pas Share, mais uniquement Explorer, ce n'est plus du collaboratif.

En bref, les limitations ont deux causes :
- l'une technique, un peu.
- l'autre par choix, beaucoup

Et si le choix a été fait, c'est aussi parce qu'il faut bien définir des priorités (et oui …).
Tout est de la faute de MoSCoW !

A terme l'interface Explorer va progressivement laisser sa place à l'interface Share. Ce qui n'est pas possible aujourd'hui le sera plus tard, et Share disposera des mêmes fonctionnalités que Explorer aujourd'hui. Simplement ça ne se fait pas en un jour. N'oublions pas que l'interface Explorer a 4 ans, et l'interface Share moins d'un an …

L'ajout de la console d'administration et des formulaires vont dans ce sens. La suite ce sera la recherche avancée, la gestion de la corbeille, et toutes ces petites choses qui manquent encore, mais qui avancent.

Je résume :
- Share dispose de moins de capacités de gestion de droit que Explorer, et c'est voulu.
- Le collaboratif restrictif, ce n'est pas idéal => plusieurs équipes = plusieurs sites.
- Un jour ce sera mieux
- Je ne suis pas bien certain que ce soit clair  :wink:

J'avais dit que je voulais faire court moi … Caramba ! Encore raté !  :?

[felie]

Merci pour ces explications approfondies.

Donc si j'ai bien compris, share dispose actuellement, et de manière délibérée, de moins de possibilités de contrôle des accès aux documents qu'avec explorer, mais devrait tout de même être aussi complet dans les versions futurs.

Du coup, j'aurais tendance à en conclure que dans le cas du besoin d'un site collaboratif avec tout de même un sérieux contrôle d'accès aux documents qui ne soit pas limité à ceux d'un CMS classique avec les rôles de lecteurs, éditeur, etc. (ce qui fait pour moi l'intérêt de l'utilisation d'un vrai système de gestion de contenu comparé à un joomla-like avec un addon de gestion de documents), je devrais plutôt créer un espace utilisateur sous share et accéder aux documents via l'explorer voire un addon type DoCASU histoire d'obtenir une interface un peu plus "user friendly" ?

Ceci dit, pour le moment, je n'ai pas encore obtenu de messages d'erreur ni constaté de dysfonctionnements en utilisant "share" pour la visualisation et la manipulation classique des documents et "explorer" en admin pour la gestion fine des accès aux divers répertoires des documents. Ceci dit, si vous me dites qu'il peut y avoir des problèmes, je vais donc devoir changer d'approche. Dommage.

  F.

[ton]

Bonjour,

n'en ayant fait qu'à ma tête, je me retrouve dans le cas où, après avoir supprimé un dossier d'un site Share depuis Alfresco Explorer, je ne peux plus creer ou supprimer quoique ce soit de ce site…
même la recherche de site plante lorsque ce site fait partie des résultats de recherche.

que faire pour retrouver une situation normale ? heeeeelp !!!