stop saving postal addresses (<contact:addr>)

[vohmar]

Starting on 1st of January 2017 EIS will stop collecting postal addresses for contact objects in .ee zone. The postal addr data will not be deleted on 1st of January - the system must igonre the data in the db.

the contact:addr part of epp contact schema postalInfoType for create element will be optional (minOccurs="0"). Create nor Update commands must not fail just because registrar adds postal address info in the epp request

If registrar send a contact create query with postal address data query is accepted and result code 1100 is returned with message "Command completed successfully; Postal address data discarded"

same goes for contact update - if contact:addr exists in contact:chg part of contact update request this data is discarded by the system the rest of the query is validated and result code 1100 is returned in case of no errors

contact info request should not return addr element in postalInfoType regardless if there is data saved in DB or not

in case of contact and domain transfers postal address data must be discarded

postal addr data rows must be removed from WHOIS results. Data must be deleted from whois db (structure will remain the same)

REPP must not return postal address data.

The functionality should be configurable in admin - checkbox for making registry not to save and return postal address data. The default setting is to collect postal address data.

Schemas that need update are (registry/lib/schemas/):

• contact-eis-1.0.xsd > contact-ee-1.1.xsd (optional contact:addr)
• epp-1.0.xsd > epp-ee-1.0.xsd (new result code 1100)
• all-ee.xsd > all-ee-1.1.xsd (references to new versions of contact and epp schemas)

The example requests for contact:create and contact:update in epp-client and xml-console of the portal for registrars must also be updated with the new versions of xml schemas. (The contact:addr element will remain in the examples to support the check box functionality of admin interface - will come back to template switching in the future).

hide address block in contact create and update views of the portal for Registrars
/registrar/contacts/new
/registrar/contacts/CONTACT:ID

[artur-intech]

@vohmar Can you confirm that the postal address consists of the following fields?

• city
• street
• zip
• country_code
• state

[vohmar]

@artur-beljajev as specified in the issue heading and respecified in the description by postal address I mean contact:addr element the subelement of contact:postalInfo in EPP schema. Please familiraise yourself with the details: https://tools.ietf.org/html/rfc5733.

You can check the subelements of contact:addr element in the rfc or EPP contact schema. These are

• contact:street
• contact:city
• contact:sp
• contact:pc
• contact:cc

[artur-intech]

I meant DB fields and the question was regarding REPP, which as I see has nothing to do with EPP (correct me if I am wrong).

[vohmar]

yes these are the db fields

[artur-intech]

What is meant by "WHOIS results"? http://prntscr.com/dfdhfk I cannot find the address here.

[vohmar]

@artur-beljajev you are correct, we do not publish postal address info of contacts in whois an thus this requirement is invalid. I removed it from the description.

[vohmar]

updated the description of the ticket with a requirement:
"The example requests for contact:create and contact:update in epp-client and xml-console of the portal for registrars must also be updated with the new versions of xml schemas."

[vohmar]

updated the description with references to necessary schema updates:
"Schemas that need update"

[artur-intech]

№ 1, № 2, № 3 Fixed by № 5, № 6, № 7
№ 4 Cannot reproduce. Check "address_processing" setting in admin and provide additional info if the issue remains
№ 5, 6, 7 Good catch, fixed. Please review this part thoroughly.

Also note related changes:
internetee/epp#1
https://github.com/internetee/depp/issues/1
internetee/EPP-web-client#10
internetee/epp-xml#3

P.S. GEMFILE dependencies of "registry" and "epp-web-client" projects are currently pointed to master branch of epp and epp-xml, so it will not work unless merged.

[vohmar]

• there is an error message on registrar portal's poll page (/registrar/poll)
  Element '{urn:ietf:params:xml:ns:epp-1.0}epp': No matching global declaration available for the validation root. [code: 2001] EPP login fails (https://staging-adm.infra.tld.ee:444/admin/epp_logs/40715)

[artur-intech]

See my last comment. This is the most probable reason.

[vohmar]

1. The postal address is still required in the portal for registrars in the contact create and update forms (local validation)

• /registrar/contacts/new
• /registrar/contacts/CONTACT:ID/edit

2. EPP-web-client returns an error if the postal address data is missing from the response

ActionView::Template::Error (uninitialized constant Depp::Contact::Country):
    20:       %dd= @contact.state
    21:
    22:       %dt= t(:country)
    23:       %dd= @contact.country_name
  app/models/depp/contact.rb:272:in `country_name'

[artur-intech]

"local validation" = client-side?

[artur-intech]

№1 Is a known issue and you have extracted it to a separate ticket #290.

[vohmar]

yes, local validation means client side - portal validates form data before sendint it to epp.
#290 is about hiding postal address form fields - this is not critical at the moment. No1 issue here is that in current form the postal address data is mandatory from client side - this is critical to solve and should be done in this ticket before it could be closed. Simple solution is to remove postal address field validations from the portal for registrars and epp web client.

[artur-intech]

Not sure you noticed #251 (comment)

[artur-intech]

№ 1 is fixed.

[vohmar]

the Address Processing chekcbox seems to have lost its function now. After enabling it I was still able to register a contact without postal address data

https://staging-adm.infra.tld.ee:444/admin/epp_logs/41221

it seems it takes some time before the settings take effect. (Cron)

[artur-intech]

What CRON?

[vohmar]

Setting.reload_settings!

[artur-intech]

Oh, good to know that such thing does exist.

[vohmar]

in production, branch deleted, closed