Issue Number | 3868 |
---|---|
Summary | [Publishing Reports] Add links to summaries on Cancer.gov |
Created | 2015-01-29 17:51:05 |
Issue Type | Improvement |
Submitted By | Juthe, Robin (NIH/NCI) [E] |
Assigned To | Englisch, Volker (NIH/NCI) [C] |
Status | Closed |
Resolved | 2015-06-09 14:38:19 |
Resolution | Fixed |
Path | /home/bkline/backups/jira/ocecdr/issue.146010 |
A nice-to-have for discussion -
Could the automated publishing report that we receive via e-mail include links to the published summaries on Cancer.gov?
I'm referring to this report:
Publishing Job Summary Report:
https://cdr.cancer.gov/cgi-bin/cdr/PubStatus.py?id=12414&type=Report&Session=Guest
Is this a request only for the summaries or for all document types?
Just the summaries for now, but if we like it we may add it to other doc types too. Thank you!
I have a question regarding this request.
The "location" within Cancer.gov for the summaries is identified by the
cdr:xref attribute of the SummaryURL element. This attribute
always assumes the host server to be http://www.cancer.gov. If I am using
this value without changing it in any way linking to the document might
not always work as expected. When the user receives the email for the
Publishing Job Summary Report from DEV, for instance, the user
would go to the document on PROD.
We have two options:
We leave the URL as it has been entered in the SummaryURL/@cdr:xref attribute with the understanding that testing on lower tiers will not work properly or
We modify the URL that's entered in the SummaryURL/@cdr:xref attribute to make it relative with the understanding that the URL might not exactly reflect the string entered in the summary document (but it would simplify testing on the lower tiers)
Which type of link should we create for the summaries - relative or absolute?
As discussed at our status meeting we want to use the absolute links (option 1).
The links to the summaries have been added to the report. The following files have been modified:
PubStatus.py
dataform.css
This is ready for review on DEV.
This looks pretty good so far, but I've come across a few URLs in my spot-checking that aren't right on DEV (therefore, the new links from the publishing report are broken). These are in docs 688139, 371825, 683767, and 256714. Two of these are Spanish and it looks like the URLs in the documents have "hp" instead of "pro" as is used on PROD and on Cancer.gov. The other two are Cannabis summaries and the word cannabis is misspelled. This is about half of the summaries I've reviewed. As long as the URLs are correct on PROD (as these are), is it safe to ignore these issues?
We really can't hide anything from you, can we? :-)
The Spanish hp vs. pro problem can be ignored. The
original spreadsheet that was loaded to update the SummaryURLs used
hp, which was for later runs - QA tier and above - changed to
pro.
If I remember correctly the Cannabis misspelling had been corrected in a
later version of the loaded spreadsheet as well.
It is save to ignore these issues on DEV.
Saved the following files in subversion:
R13208: PubStatus.py
R13209: dataform.css
Several URLs on QA are resulting in page not found errors. These are for the following summaries: 256757, 688139, 446574, 598505, 256851, 765468, 371825, 617025, 765718, 728604, 448614. These are for the English and Spanish, HP and PT summaries published between 1/1/16 and 6/19/15. It looks like some are missing "tipos" in the URL, some have "cam" instead of "mca", and "Cannabis" is misspelled in some, as we saw on DEV. I'm guessing we can ignore these problems if they are correct on PROD, right?
If the URL for these problem summaries is different from what it is on Cancer.gov we should ignore the errors. There were several URL changes between QA and PROD and I don't think the QA database had been refreshed from PROD since we ran the global change to adjust the URLs. As long as some - hopefully most - of the URLs work we should be good.
Thanks. Verified on QA.
This has been copied to PROD.
Please verify and close this ticket.
Verified on PROD. Closing issue.
Elapsed: 0:00:00.001758