ID for Owner Identification in Another Problem Management System Capability?
Hi All,
In our Integration Test, we test the release and are the first customer. We also open Service Requests (PMRs) for problems after service-transfer or in-service products and components. When we identify a problem for these in-service items or special requests, we use the local tracking system for our local tracking, and also open the service-request (PMR) to level two for debugging (problem determination) and defect identification. In our local tracking system we then identify the owner (Owned By) as LEVEL-TWO to indicate the area that currently owns the PD and defect identification. We used Rational CQ and that allowed us to identify LEVEL-TWO as the owner and it does not notify anyone. This is because Level 2 does not want notification from local tracking or customer systems and all communications are done via the PMR or service-request.
The question I have is: Is it possible in RTC to have a userID identified, like LEVEL_TWO, without an e-mail, so it does not notify anyone? Or is there a way that this can be accomplished? I am being told that this is not possible, so would like to get the answer from development, if possible.
Another question would be: Can you have in RTC a group concept like CQ, where you can identify multiple people in a group, say a development group, for complete identification and notification of an open problem?
Thank you for any help.
....Al
In our Integration Test, we test the release and are the first customer. We also open Service Requests (PMRs) for problems after service-transfer or in-service products and components. When we identify a problem for these in-service items or special requests, we use the local tracking system for our local tracking, and also open the service-request (PMR) to level two for debugging (problem determination) and defect identification. In our local tracking system we then identify the owner (Owned By) as LEVEL-TWO to indicate the area that currently owns the PD and defect identification. We used Rational CQ and that allowed us to identify LEVEL-TWO as the owner and it does not notify anyone. This is because Level 2 does not want notification from local tracking or customer systems and all communications are done via the PMR or service-request.
The question I have is: Is it possible in RTC to have a userID identified, like LEVEL_TWO, without an e-mail, so it does not notify anyone? Or is there a way that this can be accomplished? I am being told that this is not possible, so would like to get the answer from development, if possible.
Another question would be: Can you have in RTC a group concept like CQ, where you can identify multiple people in a group, say a development group, for complete identification and notification of an open problem?
Thank you for any help.
....Al
Accepted answer
Users, user ID's and e-mails:
When creating a user manually the e-mail address has to be provided. It however only has to conform to the proper format and it does not have to be a real address or could be automatically dumped.
So you could create technical or other "users" that could own work items but they would not necessarily have to receive e-mail notifications. Also you can change the notification preferences for technical users.
I am just wondering, why you would want to have the item owned by a technical user, if there is no reason or benefit in doing that. Since it is not a real user, I don't see any value in it. I would rather look into states or the like if you want to have some information that a work item has been triaged.
RTC does not know groups. RTC has the concept of project and team areas, which have members. It knows the concept of access groups that actually is used for a completely different purpose, however you can manage them (server wide) and they can contain project/team areas as as well as individual users.
There is no built in notification implemented for groups, so you would have to create a custom notification mechanism as well.
It is theoretically possible to use a work item type and user list attributes to create some artificial group concept, but the ui handling would feel funny, I think. Again, no notification out of the box and you would have to write some custom solution.
When creating a user manually the e-mail address has to be provided. It however only has to conform to the proper format and it does not have to be a real address or could be automatically dumped.
So you could create technical or other "users" that could own work items but they would not necessarily have to receive e-mail notifications. Also you can change the notification preferences for technical users.
I am just wondering, why you would want to have the item owned by a technical user, if there is no reason or benefit in doing that. Since it is not a real user, I don't see any value in it. I would rather look into states or the like if you want to have some information that a work item has been triaged.
RTC does not know groups. RTC has the concept of project and team areas, which have members. It knows the concept of access groups that actually is used for a completely different purpose, however you can manage them (server wide) and they can contain project/team areas as as well as individual users.
There is no built in notification implemented for groups, so you would have to create a custom notification mechanism as well.
It is theoretically possible to use a work item type and user list attributes to create some artificial group concept, but the ui handling would feel funny, I think. Again, no notification out of the box and you would have to write some custom solution.
Comments
Thank you Ralph. Having that indication in the Owned By field would give us the same process as we use today. However, having an indication in the state is interesting.
What you basically want to be able to show is
- An incoming item that has not been triaged
- find the triaged items in your backlog
There are several ways to do this. One is to have the convention that
- Anything that is not filed against an iteration is not triaged
- Use a backlog iteration to triage all the items that are not yet planned for an iteration
Another way would be to have a state that you move the item into which basically shows the item was triaged.
Anything that can be implemented with a simple work item query is valid.