Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 804530 - PRD35 - [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is selected as the fencing type
Summary: PRD35 - [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.0.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.5.0
Assignee: Eli Mesika
QA Contact: sefi litmanovich
URL:
Whiteboard: infra
Depends On:
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2012-03-19 07:47 UTC by Sadique Puthen
Modified: 2019-03-22 07:05 UTC (History)
20 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-02-11 17:49:54 UTC
oVirt Team: Infra
Target Upstream Version:
dyasny: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC
oVirt gerrit 25969 None None None Never

Comment 1 Itamar Heim 2012-06-17 18:42:40 UTC
*** Bug 690314 has been marked as a duplicate of this bug. ***

Comment 3 Eli Mesika 2013-01-14 15:28:36 UTC
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 06:49:51 UTC
(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 12:45:56 UTC
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 09:53:30 UTC
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 10:02:23 UTC
(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 14:24:50 UTC
Yes, ack.

Comment 13 sefi litmanovich 2014-06-24 14:52:25 UTC
Verified on ovirt-3.5.0-alpha1.

Comment 16 errata-xmlrpc 2015-02-11 17:49:54 UTC
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.