![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: Forward problem with CM6.3/CS4.3 Topic Summary: Created On: 25-Nov-2003 08:57 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hello,
I try to to set up CR forwarding on the "dev_process" CRprocess between the state in_review and a new state forwarded So, In CCM_HOME/etc/ptcli.cfg, I uncomment the line: [PARAMETER][TYPE]problem[/TYPE][NAME]forward[/NAME][VALUE]product_name|produ ct_subsys[/VALUE][/PARAMETER] I Define values and database mappings in database/pt/dbmap.dft I Define the list of attributes to forward in database/pt/mailatts I add a state named "forwarded" in the lifecycle with a transition In_review2forwarded name "Forward" and then configure the ChangeSynergy installation and database for forwarding. My problem is that AS SOON AS the couple product_name|product_subsys is mapping a couple link with a forwarding address, the CR s forwarded. EVEN IF the CR is not transitionning the In_review2forwarded transition. FOR EXAMPLE, during submission (transition START_HERE2entered): if the couple product_name|product_subsys is mapping a couple link with a forwarding address, the CR is directly forwarded and not created!!!! In the past ( with CS3.5), we remove the product_subsytem attribute from the Submit dialog window to avoid such behavior. But The attribute is now requested by the project in the submit Dialog Do you have any clue to controll correctly the forward action according the lifecycle definition i specify? Best regards. |
|
![]() |
|
![]() |
|
Hi Pascal
Problem Forwarding has been largely superceded by DCS which uses the DCM replication facilities to transfer CRs between databases. This mechanism has the advantage that it can also pass updates made to the CR back to the originating database. This means that anyone viewing the CR in the originating database will be able to see as it progresses through its lifecycle in the receiving database. DCS also enables control of the CR to be handed back to the originating database (or to any other database in your DCM cluster). In my opinion, DCS is a far more flexible mechanism than problem forwarding, in which visibility of the CR is lost as soon as it is forwarded. Now to answer your question: The simplest way to solve this problem would be to remove the product_subsystem attribute from the submission view and only prompt for it during the in_revew2forwarded transition. If your project team really cannot live with this solution, I would suggest changing the attribute that triggers the forwarding mechanism: e.g. create a new attribute called verified_subsystem, only prompt for it on the in_review2forwarded transition, and then set your forwarding to be trggered by verified_subsystem instead of product_subsystem. I would probably take this a step further by creating a custom control for verified_subsystem that makes it a hidden control and automatically copies its value from product_subsystem. This custom control could be placed on the in_review2forwarded transition view so the simple action of making the transition will automatically set the verified_subsystem attribute and hence trigger the forwading mechanism to operate. cheers Paul |
|
![]() |
Telelogic SYNERGY
» SYNERGY/Change
»
Forward problem with CM6.3/CS4.3
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.