![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: Different submit forms based on problem type? Topic Summary: Is there a way to have different submissions dialogs for defects and enhancements. Created On: 6-Jan-2006 18:33 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
We are about to upgrade to 4.4. We have been running 4.2 with a custom package that has a "Submit Defect" and "Submit Enhancement" pair of buttons. All these do is route to different HTML pages that contain different fields for submission for defects compared to enhancements (creating a CR with either problem_type='defect' or problem_type='enhancement' in the process). |
|
![]() |
|
![]() |
|
I believe that it is not possible directly, as you have suggested.
However, your suggestion of "entered" and "defentered" states suggests the following posibility but it is an untested suggestion:
TRELATIONs are defined in ptcli.cfg in the $CCMHOME/etc directory. This is a self-documenting file (say Telelogic). The following hints may help, if you haven't played with this before: - ACTION= "set" - REL_NAME = "self" - ATTR_NAME = "crstatus" - ATTR_VALUE = "entered" The following is an example of a TRELATION I have defined to set an attribute on creation. However, I do not know if this will work with the crstatus attribute. |
|
![]() |
|
![]() |
|
I had the same task in the past and I solved this by doing the following:
1. create for all states you want to use within the lifecycle parallel states like this:
cr_entered (for Change Request) and entered (for Problem Reports)
cr_in_review and in_review and so on...
2. create all transition forms you need, e.g. cr_entered2cr_in_review. These forms now allow you to have a complete different look and feel than the form for entered2in_review, this a really helpful.
3. the most important part is to define in the ptcli.cfg the postconditions for the merging of the parallel state into you lifecycle like this:
[TRELATION]
[NAME]verify change request[/NAME]
[ACTION]verify[/ACTION]
[REL_NAME]self[/REL_NAME]
[ATTR_NAME]crstatus[/ATTR_NAME]
[ATTR_VALUE]cr_entered[/ATTR_VALUE]
[/TRELATION]
[TRELATION]
[NAME]set change request crstatus to entered[/NAME]
[ACTION]set[/ACTION]
[REL_NAME]self[/REL_NAME]
[ATTR_NAME]crstatus[/ATTR_NAME]
[ATTR_VALUE]entered[/ATTR_VALUE]
[/TRELATION]
4. define the postconditions in the lifecycle and make sure that the crstatus is on the transition form modifiable.
5. use attribute security to exclude the crstatus from all modifiable attributes for normal users.
6. create package....
This is working, we are using it.
Good Luck,
Andrea
|
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.