David is, as usual, spot on. Overlays are not put there for us to have any sense of invincibility or impunity when altering OOB forms or workflow that we under other circumstances would (or should) know better than to alter. It is a means to protect additions that may conflict with FUTURE OOB functionality. That it also gives one the ability to protect against having customizations to PRESENT forms and workflow is an incidental increase in power that we should work hard to wield carefully.
It is, in a nutshell, like developing in Remedy (or C, for that matter). The best thing about it is that you can do anything you want. The worst thing is that you can do anything you want. Rick On Tue, Feb 1, 2011 at 3:48 PM, Easter, David <[email protected]> wrote: > ** > > Overlays is the most important feature that you should never use. J > > > > 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]> 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] > 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 > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > > _attend WWRUG11 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"
