FHIR Chat · Error handling email address · IG creation

Stream: IG creation

Topic: Error handling email address


view this post on Zulip Alexander Henket (Feb 14 2020 at 11:48):

I get a lot of (thousands) of messages in qa.html that read:

The link 'info@nictiz.nl' for "Nictiz" cannot be resolved

This is probably based on our contact data in every ig and conformance resource:

<contact>
    <name value="Nictiz"/>
    <telecom>
        <system value="email"/>
        <value value="info@nictiz.nl"/>
        <use value="work"/>
    </telecom>
</contact>

Is it necessary to include mailto: with that value when the system already clearly says it is an email address?

view this post on Zulip Michael Lawley (Feb 15 2020 at 01:37):

Hmm, we get same problem. Looking at the code it appears that HTLMLInspector.java is checking all HTML a hrefs and thus I suspect it is the template that is failing to insert the mailto: prefix.

view this post on Zulip Michael Lawley (Feb 15 2020 at 01:55):

I suspect this line in the page-end template is the culprit:

IG &#169; {{site.data.info.copyrightyear}} <a style="color: #81BEF7" href="{{site.data.fhir.ig.contact[0].telecom[0]}}">{{site.data.fhir.ig.publisher}}</a>.  Package {{site.data.fhir.packageId}}#{{site.data.fhir.igVer}} based on <a style="color: #81BEF7" href="{{site.data.fhir.path}}">FHIR {{site.data.fhir.version}}</a>. Generated <span title="{{site.data.fhir.genDate}}">{{site.data.fhir.genDate | date: "%Y-%m-%d"}}</span>

As it assumes the first telecom in the first contact is a URL.

The simplest work-around would be to add a URL telecom before the email one.

view this post on Zulip Grahame Grieve (Feb 15 2020 at 02:33):

I looked into this- the problem is not in the resource, but in the template that assumes that the email address has a mailto:prefix, when it doesn't. @Lloyd McKenzie I think that's the base template

view this post on Zulip Lloyd McKenzie (Feb 15 2020 at 06:52):

Is email allowed to have the mailto: prefix or do I need to add logic that checks if it's already there? (It would be nice if we required it to be one way or the other.)

view this post on Zulip Lloyd McKenzie (Feb 15 2020 at 06:53):

Also, I guess you need to release the base template so I can make more changes to it.

view this post on Zulip Alexander Henket (Feb 15 2020 at 07:54):

I don't see any hint on how you should format value when system is email. Agree that being specific one way or the other would be best. Given that it was never a requirement, it might be hard to be specific now, so perhaps assuming that it may or may not be there at present is all you can do in general, but ... I would assume that making the IG guidelines more strict actually is an option.

Since you could not do a url without scheme, I don't see why you could not be specific for email (and phone|pager|fax|sms which are all tel:). Not sure what to do with "other" in the IG footer.

Note that this whole thing is only relevant for the first telecom as that is linked into the footer. All others are "nice-to-know"

In short: I would propose an invariant for the first IG.contact.telecom.value that requires it being a valid URL.

view this post on Zulip Grahame Grieve (Feb 17 2020 at 01:00):

email should just be the email address, and should not have mailto: prefixed. But since we apparently failed to be specific about this (though the provided example is fairly suggestive), I guess you'll have to handle both

view this post on Zulip Grahame Grieve (Feb 17 2020 at 01:01):

I guess you need to release the base template

And update all the dependencies?

view this post on Zulip Lloyd McKenzie (Feb 17 2020 at 03:16):

Yes

view this post on Zulip Grahame Grieve (Feb 17 2020 at 03:25):

so before I can do the release you need to make another entry in the package-list.json file, filling in everything but the date (make that XXXX-XX-XX), and changing current = false for the last released version

view this post on Zulip Grahame Grieve (Feb 17 2020 at 03:26):

let me know when you've committed it

view this post on Zulip Lloyd McKenzie (Feb 17 2020 at 03:55):

Done

view this post on Zulip Grahame Grieve (Feb 17 2020 at 04:46):

hmm. check change I made in the package-list.json for how it should be

view this post on Zulip Grahame Grieve (Feb 17 2020 at 04:47):

if you increase the minor version, does that bump the minor version of all the dependent packages?

view this post on Zulip Grahame Grieve (Feb 17 2020 at 04:51):

I think it does

view this post on Zulip Lloyd McKenzie (Feb 17 2020 at 06:56):

y

view this post on Zulip Grahame Grieve (Feb 17 2020 at 11:19):

ok released

view this post on Zulip Bob Milius (Apr 02 2020 at 21:37):

I'm using fhir.base.template and am getting a lot of
The link 'bmilius@nmdp.org' for "NMDP/Be The Match" cannot be resolved
Basically, found in the footer of every page.
I think it's picking it up from my package.json file containing

{
  "name": "hla-reporting",
  "version": "0.1.0",
  "canonical": "http://fhir.nmdp.org/ig/hla-reporting",
  "url": "http://fhir.nmdp.org/ig/hla-reporting",
  "title": "HLA Reporting Implementation Guide",
  "description": "How to report HLA genotyping using FHIR",
  "dependencies": {
    "hl7.fhir.r4.core": "4.0.1",
    "hl7.fhir.uv.genomics-reporting": "1.0.0"
  },
  "keywords": [
    "HLA",
    "Genotype",
    "Lab results",
    "genomics reporting"
  ],
  "language": "en",
  "author": "NMDP/Be The Match",
  "maintainers": [
    {
      "name": "Bob Milius",
      "email": "bmilius@nmdp.org"
    }
  ],
  "license": "CC0-1.0"
}

Is this another template issue?

view this post on Zulip Lloyd McKenzie (Apr 02 2020 at 22:08):

Not from there I don't think. The footer doesn't grab from the package.json, it grabs from the ImplementationGuide. What's in your IG file?

view this post on Zulip Bob Milius (Apr 02 2020 at 22:12):

my ImplementationGuide-hla-reporting.json?

view this post on Zulip Lloyd McKenzie (Apr 02 2020 at 22:15):

y

view this post on Zulip Bob Milius (Apr 02 2020 at 22:16):

ImplementationGuide-hla-reporting.json
(created by sushi)


Last updated: Apr 12 2022 at 19:14 UTC