Error retrying ix-###: {'sales_email': ['Enter a valid email address.']}

[ccaputo]

If ix / sales_email has multiple email addresses, which the web interface allows to be entered, peeringdb-py will balk with:

Error retrying ix-###: {'sales_email': ['Enter a valid email address.']}

Either the web interface needs to prevent the entry of multiple email addresses, or the peeringdb-py code needs to allow it.

Other fields where this may also happen need to be fixed accordingly.

[jackcarrozzo]

I think we ran into something similar to this with ixf email addrs about 6 months ago when testing the ixf timeout changes, do you recall the context @vegu ?

[vegu]

I don't recall the context, but my take away is that there is a bug that allows for multiple emails to be entered into a field that is designed to keep one email and that should be fixed.

The peeringdb-py client correctly tries to validate it to one email (and fails), i am not sure this needs to be adjusted unless we decide the system needs to support multiple emails. Server side data should be cleaned up.

Either the web interface needs to prevent the entry of multiple email addresses, or the peeringdb-py code needs to allow it.

If multiple emails need to be supported i think that's a separate issue that may need appropriate design on the server side.

I think for now we need to ensure the any entry point that allows setting of these fields (web, api, django-admin, ...) on the server side correctly validates the field to one email address.

[arnoldnipper]

I think for now we need to ensure the any entry point that allows setting of these fields (web, api, django-admin, ...) on the server side correctly validates the field to one email address.

What about allowing a list of email addresses, like email1@addr.ess1,email2@addr.ess2? Would that break anything?

[jackcarrozzo]

Thanks @vegu !

Sounds like it would require development work @arnoldnipper , more than just fixing the field validation in the ui.

Is there a strong use case for multiple emails or can we just fix the validation?

[leovegoda]

I'll get @20c-ed to have a look at a more graceful approach for now. We can discuss whether a list of addresses should be acceptable when the immediate problem is resolved.

[arnoldnipper]

Sounds like it would require development work @arnoldnipper , more than just fixing the field validation in the ui.

Is there a strong use case for multiple emails or can we just fix the validation?

Allowing a list requires less development work than fixing the validation, IMO. As users are using multiple emails there seem to be a use case.

[arnoldnipper]

Is there a strong use case for multiple emails or can we just fix the validation?

Obviously ... when looking at the latest poc records I see duplicate entries for

    168 Abuse
     34 Maintenance
   1067 NOC
    368 Policy
     21 Public Relations
     44 Sales
   1333 Technical

[arnoldnipper]

Is there a strong use case for multiple emails or can we just fix the validation?

Looking at net/346 shows a strong use case. Obviously, the network wants to publish the names of the Peering Managers. The email address however points to the same address. Clever way, IMO.

[ccaputo]

If ix / sales_email has multiple email addresses, which the web interface allows to be entered, peeringdb-py will balk with:

Error retrying ix-###: {'sales_email': ['Enter a valid email address.']}

Either the web interface needs to prevent the entry of multiple email addresses, or the peeringdb-py code needs to allow it.

Other fields where this may also happen need to be fixed accordingly.

I found another example of this happening. The web interface allows a typo such as "foo@examplenet" (typo being there is just a TLD) while peeringdb-py will balk at that.