Si l'on regarde un peu la documentation du DCWorkflow, on découvre que les worklists offrent assez peu de possibilité du fait que peu de variables de noms sont utilisables. On dispose donc (en plus de valeurs statiques comme l'état de workflow qui seront les mêmes quelque soit le context du document ou de l'utilisateur) de :

  • portal_url : le path du portail

  • folder_url : le path du folder conteneur de l'objet

  • content_url : le path de l'objet

  • user_id : le username de l'utilisateur authentifié

  • count (spécifique à la worklist) : le nombre de résultats correspondant aux critères des cataloged variables matches

Ce qui est maigre pour faire des subdivisions de worklists. Comment faire donc pour limiter les nombres de résultats fournit au Reviewer sans créer pour autant 15 rôles reviewer like spécifiques et autant de portal_type / workflow / worklist ?

Deux des variables précédentes sont utilisables avec de bons résultats :

  • user_id qui va nous permettre d'identifier le Reviewer parmis les autres

  • folder_url qui va nous permettre d'identifier l'emplacement actuel de navigation

Problèmes :

  • nous n'avons que ces valeurs et pas vraiment de moyen d'en tirer autre chose (comme par exemple un rôle/groupe que l'on obtiendrait au moyen d'un script ou d'une external method). Il faut donc se débrouiller avec ces valeurs et travailler de l'autre côté : fournir une liste de username ou de path dans l'index où l'on effectue la recherche ;

  • de plus, il est nécessaire de travailler sur deux recherches distinctes :

    • les cataloged variables matches qui sont les variables de workflow avec l'option make avaible to catalog. Elles servent uniquement à déternimer le nombre de documents fournit par la worklist (la variable count et donc le chiffre indiqué dans l'action box) ;

    • les variables de recherche fournit dans l'url de l'action de la worklist ; qui sont les critères effectifs de recherche pour obtenir les documents dans la page de résultats.

**Exemple d'utilisation : un reviewer spécifique à un groupe d'utilisateur**

Dans mon workflow, j'ajoute une variable de workflow que j'utiliserai dans ma worklist et dont la valeur se calcul au moyen d'un script :

Id

groupUsers

Description

les usernames des membres du groupe

Make available to catalog

oui

Store in workflow status

oui [mais sans influence pour notre exemple]

Variable update mode

update only (...) when specifies a new value

Default value

Default expression

python:here.getGroupUsers(params)

Info guard

Cette variable se met donc à jour quand on l'appel (l'expression est évaluée à chaque fois) :

  • ou via un getInfoFor ;

  • ou lors d'une indexation de catalog.

Je n'ai pas fixé de guard mais il s'agit ici de règles de sécurité qui dépendent du site et non de la fonctionnalité que nous étudions.

L'expression utilise simplement un script python qui se trouve dans les skins (here fait référence à l'objet depuis lequel on appel la variable c'est à dire le context du document) et qui nous renvoit une liste de usernames correspondant au(x) paramètre(s) transmit. Par exemple on fournit le nom du créateur du document ce qui permet à notre script de retrouver son groupe et donc tous les utilisateurs qui en sont membre. Ceci peut demander certains droits voire une external method mais cela dépend de votre solution de groupes qui peut être réaliser de différentes façon (roles via GRUF ou simple propriété du portal_memberdata tool).

Ma variable contient donc la liste des id d'utilisateurs membre du groupe. Il ne me reste plus qu'à rechercher dedans l'id de notre user pour voir s'il est membre du groupe et donc Revewier de ce groupe. D'où la worklist :

Id

review_queue

Description

documents en attente pour le groupe du Reviewer

Catalogued variable matches

review_state =

Pending

groupUsers =

%(user_id)s

Display in actions box

Name

Document(s) en attente (%(count)d)

URL

%(portalurl)s/search?reviewstate=Pending&groupUsers=%(user_id)s

Category

global

Guard

Permission(s)

Role(s)

Reviewer

Expression

Remarques importantes :

  • donner l'option make avaible to catalog à une variable de workflow ne dispense pas d'ajouter l'index dans le catalog (pour mon exemple j'ai ajouté un KeywordIndex nommé groupUsers à mon catalog) ;

  • si la variable de workflow est réévaluée à chaque fois pour le count, la liste indexée dans le catalog ne l'est que lors d'une transition (reindex du document intégré au process du workflow), il faut donc reindexer notre index groupUsers lorsque l'on modifie les utilisateurs de notre groupe (via un script si vous avez skinné cette configuration).

L'utilisation de folder_url se base sur le même principe : une variable stock le ou les path(s) où l'on veut publier notre document, notre Reviewer aura une worklist spécifique lorsqu'il naviguera à dans ce path. De même, on peut jouer sur l'attribution du role Reviewer via local role dans tel ou tel path. Et ainsi avoir un Reviewer par path qui n'aura à validiter que les documents le concernant.

En conclusion, par combinaison de ces deux critères, on peut recréer une revue de publication contextuelle qui varie en fonction de l'arborescence du portail et de l'appartenance à un ou plusieurs groupes.

Note finale :

Ceci est une solution (parmis d'autres certainement) que j'ai trouvé après recherches et tests pour un cas d'application précis. Je l'ai testé uniquement sur CMF 1.4 . Le but est essentiellement de réaliser ceci par configuration simple (un script python, voir deux si on a skinné la gestion de groupes).

Je sais que l'on peut faire mieux ou plus simple par programmation (mais est-ce réutilisable ou abordable aux autres utilisateurs/dévelloppeurs ?).

Je suis ouvert à tout retours et/ou correctifs et/ou remarques sur l'utilisation des worklists (je suis peut-être passé à côté de quelquechose comme le moyen d'appeler un script du côté des variable match).