There is a defect open for this : SW00462392, but BMC considers this a RFE.
Thank you for the information about what they did. It makes it a bit more clear about they did it, but it still does not help me sell the upgrade. The is more to it than just the process itself. This change impacts a large number of Business objects reports and will require that we evaluate whether the latest version's universe, 7.6.6., takes into account the new structure. We are forced to upgrade that application and to rewrite report. So, our upgrade path has gotten more complicated than we anticipated. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of RainingRemedy Sent: Friday, January 17, 2014 1:07 AM To: [email protected] Subject: Re: CMDB 8.1 Status bug? Jesus, This is not considered a bug. The AssetLifeCycle status field has been effectively moved from the CMDB forms and placed on the AST:Attributes form. The Status field you see is just the leftover core field that is not being used. From what I've read, I don't think there is any plan to use that field in the future. Would be curious to see what BMC says about it. The whole point of the CMDB and Asset split was to separate the configuration(discovery) of CIs with the lifecycle managing (Asset Mgmt) of the CI. That is why they reconstructed all of the joins and now all the classes are joined with the AST:Attributes form. This is the form where all lifecycle managed attributes will be stored. These are typically non-discovered attributes like financial info, location info, status, etc. The CMDB forms are now in theory supposed to only be tracking what is discovered, or the configuration of a CI. The configuration may change several times during the lifecycle of the CI however, the actual lifecycle attributes can remain the same. This is the vision BMC had when they split the attributes up. Config data in one spot, lifecycle management data in another spot. As far as your current scenario is concerned, why do you need to use the status field as the trigger to promote the data into the production dataset? Would it be possible to bring in the data as you do now, allow the asset admins to modify the data as you stated, and then when they are finished the admins could set a custom attribute to "Ready for Import" for example? Then during the Identify and Merge job you could just set the Status field of these CIs to Constant "In Inventory" as stated in your process? Not sure if something like this would work in your case without knowing more info about your integration and process. Just trying to throw an idea out there as a work around. -- View this message in context: http://ars-action-request-system.1093659.n2.nabble.com/CMDB-8-1-Status-bug-tp7594610p7594641.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" Information contained in this email is subject to the disclaimer found by clicking on the following link: http://www.lyondellbasell.com/Footer/Disclaimer/ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
