Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

  • Created by Unknown User (bjfree@free-man.net), last modified on Aug 10, 2008
  1. overview
    change the Postaladdress entity to support more address and direction lines
    refer to Extending PostalAddress Information
  2. scope
    work with the PostalAddress entity and associated entities.
    1. remove the fields toName and attnName and add them as ContactMech types that can relate to the Postaladdress entity
    2. add a one to many from PostalAddress to Address line entity
    3. add a one to many from postalAddress to Direction Lines Entity
    4. add a one to many from postalAddress to Premises Entity related to Postal Address. The many is for like office buildings or apt complexs if the postal address is the main address without the office or apt specified.
  3. Justification
  • the current format only supports the US addressing mode
  • the ability to validate a address that never changes should be a one time thing to there should only be one address entry in the database.
  1. Considerations
    1. overview
      This is a major schema Change. so upgrade support is necessary for those with Live systems.
    2. Scope
      Using eca's provide two way updates.
      1. If the data is in the legacy format put in the new format
      2. if the data is in the new format put in the legacy format till the conversion process it complete.
  2. Upgrade process
    1. What will be effected
      • PostalAddress entity
      • ContactMechTypes
      • ContactMech
    2. how to change
      • change PostalAddress from package-name="org.ofbiz.party.contact" to package-name="org.ofbiz.party.postal.
      • Create and move from PostalAddress.toName and PostalAddress.attnName contact Mech for each field and link to postal address.
      • remove PostalAddress.toName and PostalAddress.attnName
      • add PostalAddress.AddresslinesID PostalAddress.DirectionsLinesID PostalAddress.PremiseID with one to many relationships.
      • Code services to keep PostalAddress.Address1 PostalAddress.address2 in sync with the new entities. put in package-name="org.ofbiz.party.postal
      • code eca's to all new services when the PostalAddress is updated. if I understand david these should be EECA's
  • No labels

4 Comments

  1. Jacques Le Roux

    I agree this is interesting. I will follow this work and post more comments when I will have read more and better understood.

    1. Jacques Le Roux

      Do we really need to move PostalAddress from package-name="org.ofbiz.party.contact" ?

      1. Unknown User (bjfree@free-man.net)

        my thought on this is there is going to be a lot of postal specific code written.
        But I default to the consensus of the group.

        1. Jacques Le Roux

          OK, so we wil see then