Actually, Sri has it right.  The CMDB console is not really an appropriate 
place to be working with CIs in general except for under special circumstances. 
 In general, you should have users creating and updating CIs using the Asset 
Management forms - it's a much better front end and can be customized.  You 
should not be customizing the CMDB forms as they are system generated.  You 
can, however, customize the Asset Management forms as much as you'd like with 
the caveat that once you do that, patches become more difficult to apply.  I 
think a good rule of thumb is that users use the Asset Management forms, and 
you only work directly with the CMDB forms when creating/updating CIs via 
integrations or when you can't do what you need with the Asset Management 
forms.  For example, running certain queries on the CMDB can be easier from the 
CMDB console, but most end users should not need to do that.  That would be 
more limited to administrators and maybe your configuration manager.

Lyle Taylor

From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of SriVamsi Patchipulusu
Sent: Wednesday, January 21, 2009 6:50 PM
To: arslist@ARSLIST.ORG
Subject: Re: best method to hide attributes in a cmdb class

** Hi Srinivas,

Thanks for replying.
The end users I meant are CMDB users that would be working on CMDB CIs.
i.e., creating/updating CIs via cmdb console.
Not the asset users.

Thanks,
Vamsi
On Wed, Jan 21, 2009 at 5:36 PM, srinivas madhurakavi 
<kavi1...@gmail.com<mailto:kavi1...@gmail.com>> wrote:
**
Sri,

If I understand your requirement correctly, these are endusers who do not want 
to see some attributes on one or more classes. So your starting form would be 
(to take the same example: Computer System Class) AST: ComputerSystem.

Since AST: ComputerSystem form is a self join of BMC_ComputerSystem with 
BMC_computerSystem which acts as a regular form you could either
1) Hide the attributes on AST:ComputerSystem form from admin tool or
2) Accomplish it via workflow

As far as I could tell, the best choice of the above two options depends on the 
number of attributes you want to hide combined with their inheritance property 
(if any).

My 2 cents,
-Srinivas
On Wed, Jan 21, 2009 at 6:41 PM, SriVamsi Patchipulusu 
<vamsi.ps<http://vamsi.ps>@gmail.com<http://gmail.com>> wrote:
** All,

I have a requirement from end users that they dont want to see some
fields in the cmdb class(Ex:BMC_ComputerSystem).

First I thougt of going to CMDB Class Manager, select the class, view
attributes and change the property hidden No to Yes.

But I can access this property only for the fields that are from
BMC_ComputerSystem_ only.
Any fields that are inherited from BMC_BaseElement,  that option is
disabled.

Now what are the options available to hide those fields that are
inherited from BMC_System onto BMC_ComputerSystem class ?

1. Directly hide it from admin tool.
--> But I dont think this is an option because it wont update the meta
data, changes will be deleted next
    the class is modifed from class manager.
2. Write an activelink to hide those fields on form open.
3.Create a new page hiddent page tab in that class and move the fields
to that new tab?
--> Can we do it because there is no option to create a page Tab from
cmdb class manager?
Thanks in advance. __Platinum Sponsor: RMI Solutions ARSlist: "Where the 
Answers Are" html___

__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___

__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___


 NOTICE: This email message is for the sole use of the intended recipient(s) 
and may contain confidential and privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender by reply email and destroy all 
copies of the original message.



_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"

Reply via email to