Community
Participate
Working Groups
The installed software view currently allows the user to drill down into detail from the root IU's. This is supported by being able to run queries on the profile, looking for root IU's, and IU's that are required by other IU's, etc. In order to show the same nested structure in an install and update wizard, we need to be able to treat the provisioning plan similarly. For example, - show me the proposed root IU's in the plan - show me the IU's required by this IU which are groups In the future these queries may take into consideration some of the issues discussed in bug #227675 (show me all the group IU's that are not categorized). The UI already builds the appropriate queries it needs, what is missing is for a provisioning plan to be able to satisfy these queries.
This is somewhat related to bug #218055, needing more structured info from a provisioning plan. However, I pulled this particular requirement out into a separate bug since it is the minimum needed in order to support drilling down into the details in an install/update/uninstall wizard. Marking M4 since the UI part of this is in the plan for M4, although it needs to happen early in the milestone or even at the end of M3. One thing that's interesting here is that it would seem the provisioning plan would need more context in how to traverse the operands to answer queries. For example, a query like "give me the group IU's" should traverse the second argument of each IU operand when dealing with install or update, but it should traverse the first argument of each IU operand when dealing with an uninstall.
As you mentioned, the difficulty is with knowing whether you are interested in the removalor the addition aspect of things. To address this I'm thinking of two approaches 1) Add to ProvisioningPlan two methods that returns IQueryable IQueryable getRemovals(); IQueryable getAdditions(); 2) Add to ProvisioningPlan two metdhos that execute a query, but not have ProvisioningPlan implement IQueryable Collector getRemovals(IQuery, Collector, Progress) Collector getAdditions(IQuery, Collector, Progress) What do you prefer? Any other idea?
Created attachment 116480 [details] Initial patch Here is an initial patch implementing idea #2. Because I did not know what to do about the updates, the IUs removed as part of an update appear in the getRemovals and the same goes for the additions.
(In reply to comment #2) > As you mentioned, the difficulty is with knowing whether you are interested in > the removalor the addition aspect of things. > To address this I'm thinking of two approaches > 1) Add to ProvisioningPlan two methods that returns IQueryable > IQueryable getRemovals(); > IQueryable getAdditions(); > 2) Add to ProvisioningPlan two metdhos that execute a query, but not have > ProvisioningPlan implement IQueryable > Collector getRemovals(IQuery, Collector, Progress) > Collector getAdditions(IQuery, Collector, Progress) > > What do you prefer? Any other idea? > I require approach #1 per comment #0. The UI views are traversed by a pluggable "QueryProvider" which gives the UI the queryable, query, and collector to use to traverse available IU's. To be able to use this code as intended, I would want to pass the plan as the queryable and use my existing queries and collectors. >Because I did not know what to > do about the updates, the IUs removed as part of an update appear in the > getRemovals and the same goes for the additions. > I think that this will work as expected for me. For the update wizard, we initially will only show the additions and see how that plays. The removals might be of interest as added information. We once talked about putting that kind of information in the status (ie, when an optional IU was removed during an update) and this might be another mechanism to show that kind of information.
>To be able to use this code as > intended, I would want to pass the plan as the queryable and use my existing > queries and collectors. I wasn't very precise here. I need to pass a queryable to use with my existing queries and collectors. So having the plan return the removals/additions as an IQueryable is what I need.
I have released things along the lines of #2. I will keep open to add tests.
I have added tests.
