Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-6882

Extend the PostalAddress entity with additional elements

    Details

      Description

      Various modern day 3rd party delivery solutions (e.g. PostNL in The Netherlands) require that elements are delivered separately, so that addresses can be checked more easily.

      Current definition of the PostalAddress doesn't have separation of:

      • street name
      • house number
      • house number addition or extension

        Issue Links

          Activity

          Hide
          pfm.smits Pierre Smits added a comment -

          This patch addresses the issue.

          It adds following elements to the PostalAddress entity:

          • houseNumber
          • houseNumberExt

          to be able to separate the address into street name (address1 field), house number and house number extension.

          It also adds:

          • cityGeoId
          • municipalityGeoId
          Show
          pfm.smits Pierre Smits added a comment - This patch addresses the issue. It adds following elements to the PostalAddress entity: houseNumber houseNumberExt to be able to separate the address into street name (address1 field), house number and house number extension. It also adds: cityGeoId municipalityGeoId
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          This sounds good to me Pierre. If nobody disagreez I will commit it in few days

          Show
          jacques.le.roux Jacques Le Roux added a comment - This sounds good to me Pierre. If nobody disagreez I will commit it in few days
          Hide
          soledad Nicolas Malin added a comment -

          I agree to extend the postalAddress entity but the improvement of main input form and at minimum completed the file applications/party/webapp/partymgr/party/contactmechtemplates/PostalAddress*.ftl is need to use these new fields (houseNumber*)

          Show
          soledad Nicolas Malin added a comment - I agree to extend the postalAddress entity but the improvement of main input form and at minimum completed the file applications/party/webapp/partymgr/party/contactmechtemplates/PostalAddress*.ftl is need to use these new fields (houseNumber*)
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Should these fields be mandatory OOTB?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Should these fields be mandatory OOTB?
          Hide
          soledad Nicolas Malin added a comment - - edited

          I think yes, I haven't problem to don't see/edit all (.?)GeoId fields because it's clearly technical but houseNumber (... oh why house ? the translator give me the english name : streetNumber ) is editable by end user

          Show
          soledad Nicolas Malin added a comment - - edited I think yes, I haven't problem to don't see/edit all (.?)GeoId fields because it's clearly technical but houseNumber (... oh why house ? the translator give me the english name : streetNumber ) is editable by end user
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          It's not clear to me if this field should be name houseNumber or streetNumber. From my research with Google houseNumber seems the right name.

          This is indeed the only field which could be mandatory. Now because of legacy, and because this is not always required, I think we should allow people to enter the house number as they did previously as part of address1. So none of these fields should be mandatory (answering my own question after being a bit more awake )

          Show
          jacques.le.roux Jacques Le Roux added a comment - It's not clear to me if this field should be name houseNumber or streetNumber. From my research with Google houseNumber seems the right name. This is indeed the only field which could be mandatory. Now because of legacy, and because this is not always required, I think we should allow people to enter the house number as they did previously as part of address1. So none of these fields should be mandatory (answering my own question after being a bit more awake )
          Hide
          pfm.smits Pierre Smits added a comment -

          Feel free to create a follow-up JIRA issue to involve the community.

          Show
          pfm.smits Pierre Smits added a comment - Feel free to create a follow-up JIRA issue to involve the community.
          Hide
          pfm.smits Pierre Smits added a comment -

          Why? Should we not leave that choice to the implementers?

          Show
          pfm.smits Pierre Smits added a comment - Why? Should we not leave that choice to the implementers?
          Hide
          pfm.smits Pierre Smits added a comment -

          I don't really care how it will be named when it goes into the codebase.

          Could also be:

          • addressNumber
          • addressNumberExt
            or just:
          • number
          • numberExt
          Show
          pfm.smits Pierre Smits added a comment - I don't really care how it will be named when it goes into the codebase. Could also be: addressNumber addressNumberExt or just: number numberExt
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          Hi, I hardly understand the difference between a Municipality and a City within the postalAddress context. Could you show me an example/explain me the diff ? Thanks

          Show
          gil portenseigne Gil Portenseigne added a comment - Hi, I hardly understand the difference between a Municipality and a City within the postalAddress context. Could you show me an example/explain me the diff ? Thanks
          Hide
          gil portenseigne Gil Portenseigne added a comment - - edited

          True, but i think that adding functionnality in datamodel must be done with adding fields in standard OOTB forms. That way, we can see easily the functionnality, then the implementer hide the not needed fields.

          Show
          gil portenseigne Gil Portenseigne added a comment - - edited True, but i think that adding functionnality in datamodel must be done with adding fields in standard OOTB forms. That way, we can see easily the functionnality, then the implementer hide the not needed fields.
          Show
          pfm.smits Pierre Smits added a comment - See http://www.differencebetween.com/difference-between-city-and-vs-municipality/
          Hide
          pfm.smits Pierre Smits added a comment -

          As I said yesterday, feel free to create a follow-up JIRA issue to involve the community

          Show
          pfm.smits Pierre Smits added a comment - As I said yesterday, feel free to create a follow-up JIRA issue to involve the community
          Hide
          gil portenseigne Gil Portenseigne added a comment -

          Thanks for the reference, but the main wonder was the within the postalAddress context, saying that it "is an administrative body with some degree of control over a geographic area", i do not know a case where city is not enough to define a postalAddress, and where municipality is needed ? It might just be an informative field %? (thinking about it while writing, it's good to me to add it, but i surely won't use it)

          Show
          gil portenseigne Gil Portenseigne added a comment - Thanks for the reference, but the main wonder was the within the postalAddress context , saying that it "is an administrative body with some degree of control over a geographic area", i do not know a case where city is not enough to define a postalAddress, and where municipality is needed ? It might just be an informative field %? (thinking about it while writing, it's good to me to add it, but i surely won't use it)
          Hide
          pfm.smits Pierre Smits added a comment -

          How postal addresses are defined and applied differs per country. So it might not apply in your situation.

          Show
          pfm.smits Pierre Smits added a comment - How postal addresses are defined and applied differs per country. So it might not apply in your situation.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks Pierre,

          Your patch is in trunk at revision: 1729198.

          If someone wants to implement these optional fields please create a Jira and submit a patch, thanks

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks Pierre, Your patch is in trunk at revision: 1729198. If someone wants to implement these optional fields please create a Jira and submit a patch, thanks

            People

            • Assignee:
              pfm.smits Pierre Smits
              Reporter:
              pfm.smits Pierre Smits
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development