Bug 995755 - webadmin [Tree]: should inform user why name cannot be edited in tree context
webadmin [Tree]: should inform user why name cannot be edited in tree context
Status: CLOSED DUPLICATE of bug 995754
Product: oVirt
Classification: Community
Component: ovirt-engine-webadmin (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Depends On:
  Show dependency treegraph
Reported: 2013-08-10 17:07 EDT by Greg Sheremeta
Modified: 2013-08-10 17:30 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-10 17:30:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Greg Sheremeta 2013-08-10 17:07:48 EDT
Description of problem:
When a specific item is selected in the left-pane tree, and a user tries to edit that item, the name is disabled for editing because the item is currently selected. This is the correct behavior. However, there should also be a message printed to the user that explains *why* the name cannot be edited.

There is code in the application to show a message, but it is not working.

In HostListModel.java
innerHostModel.getName().setInfo("Cannot edit Host's Name in this tree context"); //$NON-NLS-1$

At current count there are about 20 of these in uicommonweb. I don't see any evidence that the application uses these messages.

How reproducible:

Steps to Reproduce:
1. Select an actual host in the tree.
2. Click edit.
3. You cannot edit the host name. There is no help to tell you why.

Actual results:
There is no help to tell you why you cannot edit the name.

Expected results:
There should be a message shown that says something like "Cannot edit Host's Name in this tree context"
Comment 1 Einav Cohen 2013-08-10 17:30:17 EDT
setInfo is deprecated. it should be replaced with a call to "setChangeProhibitionReason". this will be taken care of in the context of bug 995754 -> marking as duplicate.

*** This bug has been marked as a duplicate of bug 995754 ***

Note You need to log in before you can comment on or make changes to this bug.