Bug 804530 - PRD35 - [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is selected as the fencing type
PRD35 - [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.0.0
Unspecified Unspecified
medium Severity medium
: ---
: 3.5.0
Assigned To: Eli Mesika
sefi litmanovich
infra
: FutureFeature
: 690314 (view as bug list)
Depends On:
Blocks: 977221 rhev3.5beta 1156165
  Show dependency treegraph
 
Reported: 2012-03-19 03:47 EDT by Sadique Puthen
Modified: 2016-02-10 14:05 EST (History)
20 users (show)

See Also:
Fixed In Version: ovirt-3.5.0-alpha1
Doc Type: Enhancement
Doc Text:
This feature changes the "Slot" field to "Service Profile" when cisco_ucs is selected as the fencing type.
Story Points: ---
Clone Of:
: 977221 (view as bug list)
Environment:
Last Closed: 2015-02-11 12:49:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dyasny: Triaged+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 25969 None None None Never

  None (edit)
Comment 1 Itamar Heim 2012-06-17 14:42:40 EDT
*** Bug 690314 has been marked as a duplicate of this bug. ***
Comment 3 Eli Mesika 2013-01-14 10:28:36 EST
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.
Comment 4 Oved Ourfali 2013-06-24 02:49:51 EDT
(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.
Comment 7 Eli Mesika 2014-01-14 07:45:56 EST
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
Comment 8 Arthur Berezin 2014-02-02 04:53:30 EST
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)
Comment 9 Eli Mesika 2014-02-02 05:02:23 EST
(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
Comment 10 Arthur Berezin 2014-02-04 09:24:50 EST
Yes, ack.
Comment 13 sefi litmanovich 2014-06-24 10:52:25 EDT
Verified on ovirt-3.5.0-alpha1.
Comment 16 errata-xmlrpc 2015-02-11 12:49:54 EST
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

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