[CPS-users-fr] CPSWorkflow.constants

Cedric Marfil cedric.marfil at capgemini.com
Mar 26 Sep 13:55:53 CEST 2006


Ce serait une autre façon de faire effectivement, mais je rencontre le même problème avec les permissions spécifiques CPS, pas de déclarations de sécurité dessus.
Où serait le mal à définir ces constantes en publiques ?
CMF le fait dans son framework, pourquoi pas CPS ?
Y a-t-il des raisons techniques à ce choix ?

--------------------------------------------------------------------------------
Cédric Marfil
Concepteur Réalisateur Intégrateur Confirmé
Tél. direct: 03.20.65.34.82
Mail: cedric.marfil at capgemini.com

Capgemini
181 rue Jules Delcenserie
59700 Marcq en Baroeul

  ----- Original Message ----- 
  From: Anahide Tchertchian 
  To: Cedric Marfil ; Liste Nuxéo 
  Sent: Tuesday, September 26, 2006 11:47 AM
  Subject: Re: [CPS-users-fr] CPSWorkflow.constants


  Cedric Marfil a écrit :
  > Bonjour,
  > Ayant le besoin de créer des workflows spécifiques, je me suis intéressé 
  > à la méthode 'verifyWorkflow' de l'installer.
  > J'ai donc construit un skin qui me retourne les workflows à installer, 
  > mais pour pouvoir définir ces derniers, j'avais besoin d'accéder aux 
  > constantes stockées dans CPSWorkflow/constants.py.
  > Quoi que je fasse, je n'avais jamais accès à ces constantes. Je me suis 
  > donc inspiré de ce qui était fait dans CPSCore/permissions.py puisque 
  > l'import de constantes de permissions fonctionnait.
  > J'ai donc ajouté au fichier constants.py le code suivant:
  >  
  > from AccessControl import ModuleSecurityInfo
  > security = ModuleSecurityInfo('Products.CPSWorkflow.constants')
  >  
  > security.declarePublic('TRANSITION_ALLOWSUB_CREATE')
  > TRANSITION_ALLOWSUB_CREATE = 10
  > security.declarePublic('TRANSITION_ALLOWSUB_DELETE')
  > TRANSITION_ALLOWSUB_DELETE = 11
  > security.declarePublic('TRANSITION_ALLOWSUB_MOVE')
  > TRANSITION_ALLOWSUB_MOVE = 12 # Into this container.
  > security.declarePublic('TRANSITION_ALLOWSUB_COPY')
  > TRANSITION_ALLOWSUB_COPY = 13 # Same...
  > .
  > .
  > .
  > Pour chaque constante déclarée, j'ai ajouté une déclaration de sécurité. 
  > Maintenant, mon code fonctionne.
  >  
  > Est-ce la bonne solution ?
  > Si oui, peut-on intégrer cette modification à CPS ?
  > Si non, quelle est la bonne solution ?

  Bonjour,

  Ca n'est pas vraiment la bonne solution : ces valeurs sont protégées, 
  non disponibles en code restreint (scripts de skin) et n'ont pas 
  réellement besoin d'être mises a sa disposition

  La bonne méthode consiste à placer le code qui décrit les workflows à 
  mettre en place en code restreint, comme c'est le cas dans l'ancienne 
  méthode CPSDefault/Extensions/cpsinstall.py.

  La meilleure méthode consiste à utiliser la configuration xml et 
  GenericSetup mais cette option n'est peut-être pas disponible pour la 
  version que vous utilisez (?).

  Cordialement,

  -- 
  Anahide Tchertchian, Nuxeo
  Mail: at at nuxeo.com - Tel: +33 (0)1 40 33 71 60
  http://www.nuxeo.com - http://www.cps-project.org
  _______________________________________________
  cps-users-fr 
  Adresse de la liste : cps-users-fr at lists.nuxeo.com
  Gestion de l'abonnement : <http://lists.nuxeo.com/mailman/listinfo/cps-users-fr>

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.
-------------- section suivante --------------
Une pièce jointe HTML a été enlevée...
URL: http://lists.nuxeo.com/pipermail/cps-users-fr/attachments/20060926/09c6e6f3/attachment.htm



This list archive provided by Nuxeo, the leaders of open source ECM. Check out the Nuxeo 5 open source, standards-based ECM project.