*** Bug 690314 has been marked as a duplicate of this bug. ***
I can see here 2 requirements for cisco_ucs agent 1) change the "Slot" field to "Service Profile" 2) Add a "Sub-Organization:" field 1) is relatively easy since it involves just changing the label of the Slot field in the case of cisco_ucs agent. We can keep in configuration the mapping between the field name (secure, slot, port) and how it should be displayed per agent then the UI should change this text accordingly 2) Up to now, we had 3 general fields for all agents : secure, slot & port However, we are playing even now with the visibility of those fields when an agent is selected/changed So, I see no issue in adding a forth "Sub-Organization:" field and playing with its visibility in the same manner The UI will have to prepend "org-" to the content of this field and insert it correctly to the agent options implicitly.
(In reply to Eli Mesika from comment #3) > I can see here 2 requirements for cisco_ucs agent > 1) change the "Slot" field to "Service Profile" > 2) Add a "Sub-Organization:" field > > 1) is relatively easy since it involves just changing the label of the Slot > field in the case of cisco_ucs agent. > We can keep in configuration the mapping between the field name (secure, > slot, port) and how it should be displayed per agent > then the UI should change this text accordingly > Actually, that's not that simple. The fact that it is all stored in the database, and that there is no abstraction on top of it, makes it harder. We can't really make the label in the configuration, as it means it won't be localized. In order to make it localized we would need to put the names of the application constants in the database, but then we would need to use reflection, which isn't supported in GWT. The best that can be done in a short cycle is to do a String comparison in the UI level for the power management type to UCS, and in that case use a different label. > 2) Up to now, we had 3 general fields for all agents : secure, slot & port > However, we are playing even now with the visibility of those fields > when an agent is selected/changed > So, I see no issue in adding a forth "Sub-Organization:" field and > playing with its visibility in the same manner > The UI will have to prepend "org-" to the content of this field and > insert it correctly to the agent options implicitly. Still need to look at this one in more depth, but looks like it can be more generic, in contrast to item #1. We would need, however, to do some manipulation of the options field in the UI level, to show the sub-org in the new field, but then send it to the engine inside the options field, but that isn't an issue as well.
Arthur, this means giving up localization for those fields, I don't think that we should allow that. UI currently does not support localization of dynamic values. I recommend closing as WONTFIX
As not all power management devices are the same we need a mechanism to introduce customizations, such as , custom labels, custom fields, field type(Password)
(In reply to Arthur Berezin from comment #8) > As not all power management devices are the same we need a mechanism to > introduce customizations, such as , custom labels, custom fields, field > type(Password) Please approve that implementing that means giving up localization for all custom fields
Yes, ack.
Verified on ovirt-3.5.0-alpha1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html