| Summary: | Cannot add RM to more than one configuration | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Albert L. Rossi <arossi> |
| Component: | RM | Assignee: | Albert L. Rossi <arossi> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | g.watson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Albert L. Rossi
The problem here resides in the logic of the wizard page. The assumption is that the wizard is either creating a new launch provider or modifying one, but that only upon creation is it possible to add a launch provider (the RM Launch Tab) to a remote service configuration. 1. If this logic is valid, then we need to enable the possibility of adding a newly created launch provider to more than one configuration. This would mean that multi-selection should be enabled and an internal API change returning an array or list would be necessary. 2. On the other hand, if we want to allow an existing launch provider to be added to a service configuration, then the final page needs an additional way of allowing this step to be skipped as well. The reason is that we need to enable the "Next" button on the preceding page in all cases, and in that way the "Finish" button will not be enabled until we get the final (Service Configuration) page; but if we are editing the RM configuration in another way, we will be forced to choose a configuration to add it to (redundantly) unless we can skip that step. The second choice seems to be the most flexible to me. We need in this case to change the button group so that it is possible to select neither of the buttons. I am still not clear on why exactly one needs to be able to map a launch provider to more than one service configuration, but this should be enabled if we wish the UI to be consistent with the internal API. Unless there are objections, I will enable both multi-selection and reconfiguring an existing provider, to provide the widest range of options. Closing this bug; it is now subsumed under 320013. *** This bug has been marked as a duplicate of bug 320013 *** |