Community
Participate
Working Groups
We currently have cases where the install/uninstall/update buttons are disabled, but there is no explanation offered to the user. Possible cases include: - the install is shared so the user cannot uninstall or update, but can install - another profile modifying operation is running One complexity here is that the action may be "locked" but we may not be able to derive why that is (whether it was explicitly locked due to permissions, or because it's a shared install, etc.)
Another case seems to be that p2 in some instances can't uninstall Update Manager installed features (see Bug 241637). In this case, the p2 notion of which plugins are installed can get out of sync with reality (what old update manager thinks is installed).
I saw that bug, but I'm not sure yet why the button is disabled in that case - it's not simply a matter of UM having installed the feature. (I posted some questions there to try to determine why the button is disabled in that case).
Also note that when we install bundles via the dropins folder we also set the IInstallableUnit.PROP_PROFILE_LOCKED_IU property. We took the stance that basically if you drop in a new bundle, then you will manage its updates. If you install something with p2, then p2 can manage its updates.
no promises for 3.5, but marking 3.5 for now to keep this on my radar. See also bug #251017
In bug 258132, I added code to the wizards to catch the case where a provisioning operation is already running and explain it there. This gives the user a nice explanation in the wizard for why something cannot be done, as well as allow them to make changes in the wizard and wait for the operation to finish running, at which time they could continue the wizard. I think we should look at the remaining cases where we disable actions and consider doing something similar in the wizards. The wizards already have the structure (and screen real estate) for describing why things can't proceed. For example, if some (but not all) selected IU's were locked, this would allow the user to deselect the locked IU's in the wizard and keep going. It allows us to handle the cases that we wish were caught by the planner in a uniform way, and will make it easier to migrate when the planner does handle more of this. For cases where changes in the wizard will not change the outcome, opening the wizard before explaining what is wrong might be annoying... we open the wizard and then slap them, but at least we explain the problem rather than just disabling a button. I think removing this logic from the actions also helps us move toward bug 256310. By removing complex logic from the actions it will be easier to migrate these classes to handlers. Marking M6 to look at these items together.
moving to M7, too much going on in M6.
I really wanted to do this, but it's getting late and our preliminary testing is showing us we need to focus on making sure all the existing function is polished. I hope to look at it early in 3.6.
*** Bug 277937 has been marked as a duplicate of this bug. ***
The most recent dup bug referred to Help>Check for Updates when update is locked for an IU. As discussed with other scenarios, would we want to open the wizard to show updates that were available in this case and then explain? The suggested explanation in that bug is > The deluxe message for me would be something like: > > - There are updates available, but you don't have the necessary permission to > perform the updates. Contact your local administrator for assistance.
consider for M5, we will not be out of the API reorg branch for M4.
I'll be focusing on UI regressions that occurred during refactoring for the rest of M5. Bugs that represent pre-existing problems or feature work are moving to M6.
my plate runneth over with API freeze bugs for M6. Marking 3.6, not sure if this will get implemented or not. Will need to be triaged against the rest.
see also bug 261928. I think we want to get to a place where all of the "reasons you can't provision" are nicely organized in the status returned by operations. Whether all of this can be done in operations, or whether there need to be hooks for UI-specific knowledge remains to be seen.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
