Community
Participate
Working Groups
Subclasses of ProvisioningOperationWizard will never use the ProfileChangeOperation it is initialized with because it will always recompute the plan when getNextPage is called. The method provisioningContextChanged is always true because provisioningContext is not initialized and getProvisioningContext() returns a new instance of ProvisioningContext. InstallWizard overrides getProvisioningContext but returns instances of ProvisioningContext
Created attachment 188089 [details] TestCase This test case is fairly simple, I've created a useless subclass of InstallOperation and the operation on the second page of the wizard is no longer of that type. In my usecase I have a subclass of an InstallOperation which sets the restart policy of the provisioning job. However, I believe this would also be an issue for users who expect their InstallOperation to use a specified ProvisioningContext (ie with some set of repos).
This surprises me because I know we have update cases where we compute the updates and preserve them in the wizard, but this is probably on the first page. Can we not just initialize the provisioning context to the one from the operation as a fix?
Also, I don't think you should assume that the operation would never change in the wizard (ie, if the user changes selections, or decides to contact all sites, or something that might change the resolution). Since these classes are internal we've not really been formal about the lifecycle, we've just done what works for the SDK. So if you need that to happen, then that is a new feature. But I agree that if nothing has changed, we shouldn't have to resolve again.
Matt could you please work on a patch?
Created attachment 188261 [details] Use ProvisioningContext from ProfileChangeOperation I believe this should fix the issue for recomputing the plan. There are a few small changes: - ProvisioningOperationWizard constructor sets the ProvisioningContext to that of the operation (if not null) - ProvisioningOperationWizard getProvisioningContext returns the context of the operation, or creates a new one - UpdateWizard getProfileChangeOperation no longer sets the ProvisioningContext (this was unnecessary as recomputePlan also sets it)
Matt, are you still working on this?
I've released the patch.
