29-11-2011 : Remettre dans le débat politique les principes du Conseil National de la Résistance
17-02-2012 : Pétition pour une protection de l’apiculture et des consommateurs face au lobby des OGM
Logo de mon site
Logo de mon site
Faire un don

Luxpopuli / eZ Publish / eZ Publish: Documentation technique / eZ Publish : Features -- Fonctionnalités / User defined Object States -- États d'objets définis par l'utilisateur





Right menu

Logo du site ez.no  Logo XHTML 1.O du W3C  Logo XHTML 1.O du W3C  Site francophone officiel de Firefox
zero papier grâce aux catalogues et promos en ligne de bonial

User defined Object States -- États d'objets définis par l'utilisateur

Date de publication: le mardi 25 janvier 2011 à 23h25
Dernière modification: par Pascal BOYER le mardi 22 novembre 2011 à 23h15

08/06/2011 1:47

Pour versions: 4.4+

The introduction of freely definable object states, possibly grouped in object state collections and coupled to the role/policy system of eZ Publish, enables a wide range of applications including typical workflow processes. By default eZ Publish has only one content object state group: "Lock" with object states "Locked" and "Not locked". But by creating freely definable object states groups with their own set of object states, the possibilities of the application can be more specifically tailored to user needs.
L'introduction d'états d'objets librement définissables, éventuellement réunis en groupes d'états d'objets et couplés au système de rôles/droits de eZ Publish, autorise un large éventail d'applications dont les processus de workflow. eZ Publish ne propose par défaut qu'un seul groupe d'état pour les objets de contenus: «Lock» contenant les états d'objets «Locked» (fermé) et «Not locked» (non fermé). En revanche, la possibilité de créer librement des groupes d'états d'objets contenant leurs propres jeux d'état d'objets permet aux applications d'être mieux adaptées aux besoins des utilisateurs.

How does it work? / Comment cela fonctionne t-il ?

Object states are typically used in workflows and other workflow-like processes. It's useful to note that although they are used in workflow processes, not all workflows use object states, nor do object states employ the eZ Publish workflow engine or the workflow system themselves. In this article the term "workflow" should generally be understood as the succession of steps rather than an eZ Publish concept.
Les états d'objets sont typiquement utilisés dans les workflows et autres processus de type workflow. Il est important de retenir que bien qu'ils soient utilisés dans les processus de workflow, tous les workflows n'utilisent pas les états d'objets pas plus que les états d'objets n'utilisent le moteur de workflow de eZ Publish ou le système de workflow eux-mêmes (???). Dans cet article, le terme de «workflow» devra être compris en tant que succession d'étapes plutôt qu'au sens de concept de eZ Publish.

A workflow defines an organized sequence of actions that will be executed while the workflow is running. A simple example of a workflow could be a newly written article (object) that is sent for approval to an editor. Since by default eZ Publish only has one content object state group, "Lock", the status of this article or object can only change from unlocked to locked during this workflow process. And once an object has been locked and submitted into such a workflow process, the object remains locked until it is either rejected or accepted. So during the time between submitting an object and its approval no further editing or correcting can be done.
But the possibilities of such workflow processes can be broadened simply through the use of freely defined object states. This allows for more states to be added, thus proving more steps in the process. By attaching policies to each state you are able to control who can do what to an object while it is in a specific state.
Because the states of an object changes throughout the work process, the transition between the states of objects must also be governed through specifically assigned policies to define who is allowed to change the state. Simply put: policies must be assigned to both the states individually, as to each state change. Keep in mind that an object can have multiple object states, but can only have one object state per object state group. Learn more about the use of object states in an editorial workflow...
Un workflow définit une séquence ordonnées d'actions qui seront exécutées pendant que le workflow tourne. Un exemple simple de workflow serait un article (objet) venant d'être rédigé et envoyé à l'éditeur pour approbation. Alors qu'eZ Publish ne propose qu'un seul groupe d'états pour les objets de contenus, «Lock», le statut de cet article ne peut évoluer que de «non fermé» à «fermé» tout au long du processus de workflow. De plus, une fois qu'un objet passe à l'état fermé puis est soumis à un tel processus de workflow, alors l'objet conserve cet état jusqu'à ce qu'il soit rejeté ou accepté. Donc, entre le moment où l'objet est soumis à approbation et le moment où il l'est effectivement il reste impossible d'éditer ou de corriger l'objet.
Mais les possibilités de tels processus de workflow peuvent être élargies simplement par le biais d'états d'objets librement définis. Cela permet d'ajouter plus d'états donc plus d'étapes au processus (???). En affectant des droits à chaque état vous pouvez contrôler qui peut faire quoi à un objet lorsqu'il est dans un état particulier.
Parce que les états d'un objet évoluent au cours du processus de workflow, la transition entre les états des objets doit également être régi par des droits spécifiquement assignés pour définir qui à l'autorisation de modifier l'état. Mettre simplemen (???)t: les droits doivent être assignés individuellement aux deux états à chaque changement d'état. Il est nécessaire de retenir qu'un objet peut avoir plusieurs états mais ne peut en avoir qu'un seul par groupe d'état d'objet. Pour en savoir d'avantage sur l'utilisation des états d'objets dans le cadre d'un workflow éditorial: eZ Publish : les états d'objet

Limitations / Limites

Some limitations of this system must be taken in consideration. First of all, freely defined object states are assigned on object level, therefor they operate on published versions only, not on translations or drafts. The second limitation is that the roles and policies, that are at the heart of this system, are not yet elaborate enough to cover all possibilities.
Certaines limites de ce système doivent être prises en considération. Tout d'abord, les états d'objets librement définissables sont assignés au niveau de l'objet. Ils opèrent donc uniquement sur les versions publiées et pas sur les traductions ou sur les brouillons. L'autre limite est que les rôles et les droits, qui sont au cœur du système, ne sont pas encore suffisamment élaborés pour couvrir toutes les possibilités.

Not so much a limitation as it is an observation, that, as mentioned before, object states can be used in workflow processes, but not all workflows use object states.
Moins une limite qu'une observation, et comme mentionné précédemment, alors que les états d'objets peuvent être employés dans les processus de workflow, tous les workflows n'utilisent pas les états d'objets.

Why not sections? / Pourquoi pas des sections ?

Sections are also often used to imitate workflow object states. Although the use of sections also makes it possible to limit and control access to content through roles and policies, it isn't capable of defining policies on state changes. Whereas user definable object states can grant policies to both the states themselves as to the transitions between states. This being said sections are still used for secure sites, where for example anonymous users are only allowed to see the default view.
Les sections sont également souvent employées pour limiter les états d'objets des workflows. Bien que l'usage des sections permette de limiter et de contrôler l'accès au contenu par le biais des rôles et des droits, il ne permet pas de définir des droits sur les changements d'état. Alors que les états d'objets définissables par l'utilisateur permettent d'accorder des droits aux états et aux transitions d'états. Ceci étant dit, les sections restent encore utilisées pour sécuriser les sites où les utilisateurs anonymes ne sont, par exemple, autoriser qu'à voir la vue par défaut.

How to create Object States / Comment créer des états d'objets

  1. To create custom object states you must first create a Content Object States Group to place them in. This can be done in the Administration Interface, under the Setup-tab.
    Afin de créer des états d'objets personnalisés vous devez tout d'abord créer un groupe d'états d'objets de contenu où les placer. Ceci se réalise à partir de l'interface d'administration sous l'onglet Administration.
    1. Click on the "States"-link in the left menu. Here you'll be able to create a new Content Object States Group.
      Cliquer alors dans le menu gauche sur le lien États. Vous pouvez maintenant créer un nouveau groupe d'états d'objets de contenu.
  2. In the newly created Content Object State Group you can then create object states matching the different phases of your work process by clicking "Create new". The first state in the group will be applied by default to all newly created objects.
    Vous pouvez créer, dans le nouveau groupe d'états d'objets de contenu, des états d'objets correspondant aux différentes phases de votre processus de travail en cliquant sur Créer un nouveau. Le premier état du groupe sera appliqué par défaut à tous les nouveaux objets créés.
  3. Next you must give the correct rights to each user or user group so they can do their part of the task and only their part, before handing over the content to the next group or user:
    Vous devez ensuite attribuer les bons droits à chaque utilisateur ou à chaque groupe d'utilisateurs afin qu'ils puissent réaliser leur part de l'action globale, et seulement la part qui leur revient, avant de remettre le contenu à un autre groupe ou à un autre utilisateur:
    1. Roles and policies can be created or modified through the User Accounts-tab. In the left menu, under "Access control" you'll find the "Roles and Policies"- link. Note that you can also be redirected to this location via the "Roles and Policies" link in the Setup-tab.
      Les rôles et droits sont créés ou modifiés à partir de l'onglet Comptes utilisateurs. Dans le menu gauche, sous Contrôle d'accès, vous trouverez le lien Rôles et droits. Retenez que vous pouvez également être redirigé vers cet emplacement à partir du lien Rôles et droits dans l'onglet Administration.
    2. For each usergroup associated to this work process, specific roles and policies must be defined to limit their access and contribution to their specific tasks.
      Pour chaque groupe d'utilisateurs associé à ce processus de travail des rôles et des droits spécifiques doivent être définis pour limiter leur accès et leur contribution aux tâches qui leur sont dévolues.
    3. Furthermore roles must be assigned to control the state transitions between each phase of the workflow.
      Les rôles peuvent être de plus assignés pour contrôler les transitions d'état entre chaque phase du workflow.
  4. Now that only authorized users can modify the state of an object and push it through the workflow, a handover-channel should be created between the different contributors. This implies that user(group)s should be notified when an object is ready for them to fulfill their task. However, this feature is not yet included by default in eZ Publish
    À présent, puisque seuls les utilisateurs habilités peuvent modifier l'état d'un objet et le transmettre/pousser dans le workflow, un canal de transfert doit être créé entre les différents contributeurs. Ceci implique que les utilisateurs ou groupes d'utilisateurs soient informés qu'un nouvel objet attend qu'ils réalisent leur tâche. Malheureusement, cet fonctionnalité n'est pas encore disponible par défaut dans eZ Publish
    4.1, but soon will be. For now this must be done manually by sending the URL of the object to the next user(group) in line.
    4.1, mais le sera très bientôt. En attendant, ceci doit être accompli manuellement en envoyant l'URI de l'objet au prochain utilisateur ou groupe d'utilisateurs en ligne (???).

An example / Exemple

It can be useful to implement a private waste bin and for this object states can easily be defined. In a private waste bin an owner can place articles without deleting them permanently, but still preventing others to read or edit them. The simplicity of removing an article out of the personal waste bin and making it visible for others is an added advantage. In this implementation an object also retains its node location(s).
Il peut être très intéressant d'implémenter une poubelle privée. Pour cela, les états d'objets seront facilement définis. Dans une poubelle privée un utilisateur peut placer des articles dont il est propriétaire sans qu'ils soient définitivement supprimés tout en les préservant de la lecture ou de l'édition par d'autres utilisateurs. La facilité avec laquelle il est possible de retirer un objet de la poubelle privée pour le rendre visible par les autres utilisateurs constitue un autre avantage. Dans cette implémentation, un objet conserve également l'emplacement de son nœud (les emplacements de ses nœuds).

How to create a personal waste bin step-by-step / Comment créer une poubelle privée étape par étape

To create a private waste bin through the Administration Interface, navigate to the Setup-tab. In the left menu, click on the the "States"-link. Here you will see a list of already existing content object state groups (by default you'll only find "Lock") and you will be able to create a new content object state group:
Pour créer une poubelle privée à partir de l'interface d'administration, placez-vous dans l'onglet Administration. Cliquez, dans le menu gauche, sur le lien États pour afficher la liste des groupes d'états d'objets déjà existants (par défaut, seul le groupe Lock est présent) et pour être en mesure de créer un nouveau groupe:

User defined object states

For this example a group "Private Wastebin" was created, which includes two object states: "Viewable Article" and "In Private Wastebin". Obviously the first allows an object to be viewed by all users, whereas the latter only allows the owner to view and edit the object. Note that the first state will always by applied as default state.
Pour cet exemple, un groupe Poubelle privée est créé contenant deux états d'objet: Article visible et Dans poubelle privée. Il est évident que le premier état permet à un objet d'être vu par les autres utilisateurs quand le second permet à un objet de n'être vu et édité que par son propriétaire. Retenez que le premier état sera toujours appliqué en tant qu'état par défaut.

User defined object states

Providing the correct rights to the owner is the next step. This must be done via the "Roles and Policies"-link, which can be accessed both under the left menu "Access control" in the "User Accounts"-tab, as through the "Roles and Policies"-link in the "Setup"-tab. Beneath the list of roles you can create a new role. The role "Owner" is added and includes policies that only allow the owner of an object to edit and read the content of an article when it has the object state "In Private Wastebin". Furthermore the owner is given the sole right to control the state transitions.Next all user(group)s are assigned to the role "Owner".
Affecter les bons droits au propriétaire constitue la prochaine étape. Pour cela, il faut cliquer sur le lien Rôle et droits accessible soit depuis le menu gauche de l'onglet Comptes utilisateurs soit depuis le lien Rôle et droits du menu gauche de l'onglet Administration. Vous pouvez créer, sous la liste des rôles, un nouveau rôle. Le rôle Propriétaire sera ajouté et contiendra des droits autorisant uniquement le propriétaire d'un objet à l'éditer et à le lire lorsque l'état de ce dernier est Dans poubelle privée. De plus, le propriétaire a le droit exclusif de contrôler les transition d'états. Ensuite, tous les utilisateurs ou groupes d'utilisateurs sont assignés au rôle Propriétaire. (???)

User defined object states

Finally the policies in the Anonymous role must also be altered in order to prevent anonymous users from viewing articles in "In Private Wastebin". In the policy regarding reading content the limitation of "State_Group_Private_Wastebin" is set to "viewable article".
Enfin, les droits du rôle Anonymous doivent également être modifiés afin d'empêcher les utilisateurs anonymes de voir les articles placés dans la poubelle privée. Pour les droits relatifs à la lectures des contenus, la limitation State_Group_Private_Wastebin sera positionnée à viewable article.

User defined object states

Use of private waste bin / Utilisation de la poubelle privée

After an article has been created and sent for publishing in the User Interface, the owner will be able to define the object state.
Après qu'un article est créé et publié dans l'interface utilisateur (???), le propriétaire pourra définir l'état de l'objet.

User defined object states

This can also be done with an already published article:
Cette opération peut être également réalisée avec un article déjà publié:

User defined object states

In the Administrator Interface, the state can be altered when you navigate to the "Content Structure"-tab. When viewing an article here, make sure the "state assignment widget" at the top of the page is enabled. If so, you'll be able to define the object state.
Dans l'interface d'administration, l'état peut être modifié à partir de l'onglet Contenus. Lorsque vous affichez un article, assurez-vous que le widget Assigner un état (???) placé en haut de la page soit activé. Le cas échéant, vous pourrez définir l'état de l'objet.

User defined object states

For another example of the use of object states, please read "eZ Publish Knowledge Series: Editorial workflow with Object States".
Un autre exemple d'utilisation des états d'objets est disponible ici: eZ Publish : les états d'objet

Commentaires