CDR Tickets

~evanscd, ~vshields, I added this ticket to kick off some discussion in our meeting tomorrow (time permitting). This would be for the Ohm release most likely so if we don't have time tomorrow, we'll find another meeting in which to discuss this. Thanks, all!

The first steps toward programmatically removing old blog post links would be

• add an attribute identifying which are blog post links

• add an attribute identifying either the date of the post or the date the link was added

• decide whether we're removing links to old blob posts or old links to blob posts

• populate the attributes

We discussed this some more and I will be adding separate tickets for the following components of this request:

• generating a spreadsheet of existing Drug Reference blocks with the NCI Type

• schema change to add a TemporaryLink attribute on the DrugReferenceType element

• global change to populate the TemporaryLink attribute in selected documents (the spreadsheet will be helpful in identifying the criteria for this)

We'll use this ticket to address the programmatic removal of DrugReference blocks for links flagged as temporary with the new attribute, but this change will be dependent upon the new tickets listed above.

It's not clear from the comments above whether the "programmatic solution" mentioned above is to be

1. an admin tool to be invoked on demand

2. a scheduled job

3. a report

We've already got a report implemented, and having a report is mentioned above as one of the possible "programmatic solutions" so perhaps there's nothing to do for this ticket. Please advise.

We were hoping this could be an automated removal of the links flagged as temporary that reach their expiration date (3 years from the date stored in the CDR). The report is simply to identify which ones are scheduled to be removed in the following month so that we can go in and remove the temporary link element from any that should not be removed. Please let me know the expected LOE though; if this is significant then we may have to work with the report initially and plan the programmatic solution down the road. Thanks.

"Automated" as in "when I invoke the removal program the software takes care of finding and removing the links"? Or "automated" as in "the software removes the links while I'm sleeping"?

Please provide an estimate for the latter. 🙂

I can get it done while you're sleeping. 🙂

Or — if you want a serious answer — I can get it done in a day or less.

I modified the title to reflect the clarified requirements (we're deleting the links, not the blog posts).

Scheduled job implemented and installed on CDR DEV.

The scheduled job ran on DEV this morning at 8am, and appeared to do the right thing. Here's the relevant portion of CDR496239 before the job ran:

and here's what it looks like now:

Hi ~bkline  Could you please manually trigger the expiring links notification email? Thanks!

Done.

Verified on DEV. Thanks!

Verified on QA. Thanks!

~juther I just noticed that the scheduled job to prune the expired links is running on DEV but not on the production server, which is running the scheduled job to report which links will be removed, but not doing the actual work to remove those links. I've reopened this ticket so we can get confirmation that both scheduled jobs should be running in production, or if that's not true, capture the decision to change the requirements in this ticket.

Thanks, ~bkline . I can't think of a reason why this shouldn't be running on PROD, so I'm glad you've noticed that so we can get it fixed.

I have installed the job to run on CDR PROD at 8am on the first of every month. I ran the job manually, but there weren't any documents to process, so either the pruning is being done manually, or the values used by this script aren't being entered (or both).