Hi,
The main problem with adding fields to the User- or Group-form is that the
data need to be entered, and sometimes modified.
1. Each time a User record is modified, that user will have all
definitions recached (arf/arv files on the Windows client)
2. Each tim a Group record is modified, ALL users will get the definitions
recached. It will also trigger a server-side recache of the definitions.
If you look at your API-logs and find a lot of ARExport()-calls, you
should suspect that you have this kind of problem in your setup.
I recommend that you go for the join-form solution.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> 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 n...@ncsu.edu
> 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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
