How to integrate Support and Development
With the release of the SPoRT bridge for RTC, we are investigating moving from CQ for our defects, to RTC. For those of you who do have Customer logged defects in RTC, how do you keep the two separate (or do you?)
Do you keep support users in a separate Team Area (or Project Area)?
Do you allow Support users to have full access to all development artifacts, just those related to released products, or only allow them to see certain record types?
Thanks,
Neal
Do you keep support users in a separate Team Area (or Project Area)?
Do you allow Support users to have full access to all development artifacts, just those related to released products, or only allow them to see certain record types?
Thanks,
Neal
Accepted answer
Neal, there are many different strategies. On Jazz.net the community can access all the work items. The work items are - as far as I know - in a different project area than the source code. The community can't access that other project area.
We have other systems that keep support requests in other systems and in these cases the external user does not have access to the data. We also have private RTC project areas for some things, that external users don't have access to.
I would suggest to contact your team and talk to a Field Technical Professional about your scenario and discuss implications. Since RTC is limited in what you can do to restrict read access compared to CQ, it would be necessary to identify potential working models. One very valid one is to keep CQ for external users and link the CQ record to a work item that is used internally to track the work, using the CQ bridge.
We have other systems that keep support requests in other systems and in these cases the external user does not have access to the data. We also have private RTC project areas for some things, that external users don't have access to.
I would suggest to contact your team and talk to a Field Technical Professional about your scenario and discuss implications. Since RTC is limited in what you can do to restrict read access compared to CQ, it would be necessary to identify potential working models. One very valid one is to keep CQ for external users and link the CQ record to a work item that is used internally to track the work, using the CQ bridge.