I use that pattern for Table fields because you can have the main table field 
and then its columns appear together on the lists when sorted with field ID’s 
so its easier to spot them on that list..

Other than table fields I like to arrange the lists by type of data (not data 
type) such as asset data, people data, etc....

Joe

From: Mahesh 
Sent: Tuesday, June 21, 2011 6:30 PM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG 
Subject: Re: changing the next Field ID -- team wants to know

** I have used something like this before.


  a.. Data Fields, Character, Date, Diary, Etc 
    a.. 900000000 – 900999999
  b.. Page, List and Tables and Columns 
    a.. 901000000 – 901999999
  c.. Buttons, Trim, Boxes, Etc. 
    a.. 902000000 – 902999999
Thanks
Mahesh


On Tue, Jun 21, 2011 at 5:17 PM, Joe Martin D'Souza <jdso...@shyle.net> wrote:

  ** 

  My personal preference still is using field ID range for type of data.. it 
helps with many things including shared workflow, matching IDs functionality, 
etc..

  Another way to do it and yet work with reserving ID ranges for different 
types of data, with no workflow required, is create a form and create all the 
fields needed in that form like a central container of all fields....

  That way the only manual step would be choosing the field ID, and once its 
chosen and created, there is no chance of duplication.. Copy that field to 
whatever application form that you want to copy it to and it would carry 
forward with most of its properties with the exception of the x. y location 
which you really do not care about...

  You would only need to change the Required, Optional attribute wherever 
needed and permissions....

  I remember actually some developers using this approach at one of the sites I 
worked at, do not remember where..



  Joe

  From: Mahesh 
  Sent: Tuesday, June 21, 2011 5:46 PM
  Newsgroups: public.remedy.arsystem.general
  To: arslist@ARSLIST.ORG 
  Subject: Re: changing the next Field ID -- team wants to know

  ** 

  You will still need to plug in the field-id manually while creating the field.

   1.       Create Two forms 

  a.       Form to configure the field ranges

  b.      Form to generate the ID sequentially (you will need to write workflow 
for this).

  2.       Export the above to a def file.

  3.       Import the def file to the developer's VM.

  4.       Configure the starting range of field-id accordingly in the form 
created in step 1(a).


  Thanks

  Mahesh



  ---------- Forwarded message ----------
  From: LJ LongWing <lj.longw...@gmail.com>
  Date: Tue, Jun 21, 2011 at 3:29 PM
  Subject: Re: changing the next Field ID -- team wants to know
  To: arslist@arslist.org


  Pritch,
  To handle that scenario we have a Field ID generator form on one of our boxes 
that every developer uses when creating fields, it gives them the 'next' in a 
line, this prevents us from having that 'merge' issue that you described.


  -----Original Message-----
  From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of pritch
  Sent: Tuesday, June 21, 2011 2:14 PM
  To: arslist@ARSLIST.ORG
  Subject: Re: changing the next Field ID -- team wants to know

  For us it's not a matter of knowing 'who did what'.  Since they are VM
  images, everyone is working on separate copies which then get's merged via
  passing of def files.  If we don't use range of field ID's, we end up with
  all sorts of conflicts when we merge the forms / workflow.

  On Tue, 21 Jun 2011 13:09:26 -0700, Jason Miller <jason.mil...@gmail.com>
  wrote:
  > Expanding on the Change History field, I have gotten into the habit of
  > typing "Created" anytime create a new object.  This gives me a reference
  as
  > to when the object was created and by who.  I like "created" because I
  can
  > click into the Change History with my right hand and type it with the
  left
  > hand.
  >
  > Jason
  > On Jun 21, 2011 11:13 AM, "Joe Martin D&apos;Souza" <jdso...@shyle.net>
  > wrote:
  >> While field ID's are one way to recognize who done what, its my opinion
  > that
  >> the best use of ranges is to identify what application or module or type
  > of
  >> data a field might belong to.. For eg 750xx1xxx to 750xx2xxxx would be
  >> fields pertaining to lets say Sales Order application...
  >>
  >> A better way to manage who done what is to have their signatures in the
  >> Change History. This way (assuming that they do leverage the use of
  >> change
  >
  >> history) you can keep track of changes done and by who for e.g. if a
  >> field
  >
  >> was created by Joe as a Optional field last year but this year Joe made
  >> it
  >
  >> Required on January and then Freddy changed its field label to XYZ on
  > Feb..
  >>
  >> If they want accountability they would have to accept some discipline
  and
  >> leverage the use of something like Change History which I think is best
  >> suited for tracking purposes right from the inception of an object to
  its
  >> extinction..
  >>
  >> Joe
  >>
  >> -----Original Message-----
  >> From: pritch
  >> Sent: Tuesday, June 21, 2011 1:43 PM Newsgroups:
  >> public.remedy.arsystem.general
  >> To: arslist@ARSLIST.ORG
  >> Subject: Re: changing the next Field ID -- team wants to know
  >>
  >> Dev Studio fires workflow? Guess I learned my something new for today
  >>
  >> On Tue, 21 Jun 2011 10:41:00 -0700, Rick Cook <remedyr...@gmail.com>
  > wrote:
  >>> Just build a custom form that looks at $USER$ and assigns the nextId
  >>> from
  >>> the form with a prefix set by the workflow.
  >>>
  >>> Rick
  >>>
  >>> On Mon, Jun 20, 2011 at 9:17 AM, patrick zandi <remedy...@gmail.com>
  >> wrote:
  >>>
  >>>> ** I have some Team Members who want to set Field ID;s -- unique for
  >>>> them..
  >>>> ---
  >>>> 3 Virtuals, with 3 different Admins..
  >>>> each admin will have their beginning point of the FeildID's
  >>>> vice the 536XXX
  >>>> 777 would be joe
  >>>> 888 would be pete
  >>>> 999 would freddy
  >>>>
  >>>>
  >>>> Anyone do this..
  >>>>
  >>>> is it as simple as arschema set nextfieldid = '750000000'; ?
  >>>>
  >>>>
  >>>> --
  >>>> Patrick Zandi
  >>>> _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"
  >>
  >>
  >
  
_______________________________________________________________________________
  >> 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"
  >
  >
  
_______________________________________________________________________________
  > 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"

  
_______________________________________________________________________________
  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"_ 

_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"

Reply via email to