Overlays is the most important feature that you should never use. :) Rick is correct. Overlays enforces best practices, but you should still consider the broader implications of modifying something vs. extending. Simply put, the basic best practice rules should be:
1. Don't modify or extend anything. Use the product OOTB. 2. If you can't use the product OOTB, *add* to the existing structure, don't modify it. Extend it by adding fields, forms, workflow, etc. that do not directly impact existing functionality 3. If and only if your situation cannot be solved either OOTB or through extending the product should you consider modifying existing objects. If you find yourself with #3, that's where overlays really helps. Overlays will create a copy of the object for you, identify it as a modified object (i.e. an overlay) and ensure that the origin object remains just as BMC shipped it to you. During run time, your overlaid object is the one that the server uses. In fact, the server does a little bit of magic behind the scenes to ensure that any calling API or workflow that uses the original name (i.e. the BMC object name) is redirected to your overlaid object. That way you don't have to change guides, API programs or other calling applications/workflow. -David J. Easter Manager of Product Management, Remedy Platform BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Cook Sent: Tuesday, February 01, 2011 01:31 PM To: [email protected] Subject: Re: Preserving customizations with overlays and custom objects ** LG, from what I know of the overlay functionality, you are correct in your assessment of its impact on customizations in an upgrade situation. It is designed to allow you to choose which customizations to protect during the upgrade. As to the User form, while you COULD alter it, I still don't think it would be a good practice to do so if you are using the ITSM suite. If you have all custom apps, that might be a different story, but probably not, because of the caching issue you referenced. Rick On Tue, Feb 1, 2011 at 3:08 PM, L G Robinson <[email protected]<mailto:[email protected]>> wrote: Hi Folks, Back in the days of ARS 4.mumble, I developed a help desk application for my organization. At that stage of my development experience, I did not understand the issues surrounding modifying Remedy objects such as the User and Group forms. In my ignorance, I added fields, changed permissions and moved stuff around on the User and Group forms. I got lucky when we transitioned to ARS 5.1.2 and I simply imported all of my stuff to the new server. It worked! Now I am more experienced and I understand the reasons why you don't modify the User and Group forms. As part of my plan to transition to 7.6, I had planned to create a form of my own to hold my additional fields and I would present them to my users through a join between my form and the User form. [You may remember that I ran into a slight problem with having too many "special" fields from the User form on my join form.] I figured this would be the best way to proceed since I was making very minimal changes to the User form. Now, as I read the "What's New in ARS 7.6.04" I see a description of the "Preserving customizations with overlays and custom objects". On the face of it, this sounds like it is designed to allow one to make changes to a BMC-supplied form such as the User form and still be relatively immune to collisions and upgrade problems. So I have two questions: - Am I understanding this new feature correctly and is it now an "ok practice" to modify the User form if I use the Overlay feature? - Is this the "best practice" method for accomplishing what I am trying to do? As a side discussion, are there performance issues with one method over the other? I recall in the back of my mind that updates to fields in the User form cause the User Cache table to be updated. Is that true and is it a performance issue? I presume it would still be true when using the Overlay method and not an issue when using the join method. I have already made a small time investment in implementing the join-form method but I am willing to scrap it in favor of the Overlay method if that is the way to go. I still want to do something similar with the Group form so now would be a good time for me to decide which way I should proceed. I appreciate any guidance you might have on these questions. Thanks. Larry Larry Robinson [email protected]<mailto:[email protected]> Office of Information Technology NC State University 919-515-5432 Voice Raleigh, NC 27695-7109 919-513-0877 FAX _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> attend wwrug11 www.wwrug.com<http://www.wwrug.com> ARSList: "Where the Answers Are" _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
