| Issue Number | 3601 |
|---|---|
| Summary | [GenProf] Mailer tracking issue |
| Created | 2013-03-26 15:28:32 |
| Issue Type | Improvement |
| Submitted By | Osei-Poku, William (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2013-09-03 15:51:23 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.107929 |
BZISSUE::5300
BZDATETIME::2013-03-26 15:28:32
BZCREATOR::William Osei-Poku
BZASSIGNEE::Bob Kline
BZQACONTACT::William Osei-Poku
There appears to be a problem with mailer tracking when recording bounced emails. In some cases the system has correctly recorded that a mailer that bounced with the right "Returned to Sender" selection has been marked as such but we are finding that in other cases, they are not marked as they are supposed to. For example:
Mailer: 744290 was mailed on 12/21/2012. It was marked as bounced on 3/8/2013. However, the mailer history shows that it was received on 01/20/2013 and that there were no changes. In this case, we expected to see a "Returned to sender" designation instead of a "None" designation.
It looks like the problem has to do with when the mailer was marked as bounced (more than 60 days since the mailer was sent). It also appears that the system records a response of "None" when there is no response or when the mailer is not marked as bounced after the expiration date.
BZDATETIME::2013-04-30 17:02:04
BZCOMMENTOR::Bob Kline
BZCOMMENT::1
I think a couple of things are at play here. First, I believe we decided to cut some corners for expired mailers, and just record a "response" with "None" for the changes category when a mailer expires (there's no "expired" value in the changes category enumeration). Second, there's no provision in the schema for multiple response blocks, so once the block is in place, there's no place to put a "Returned to sender" response. If you want to change these behaviors, please describe what you would like the software to do, and we'll decide if it's feasible, and if so, what the level of effort would be (and whether CBIIT will allow us to make the changes).
BZDATETIME::2013-05-08 17:21:20
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::2
(In reply to comment #1)
> If you want to change these behaviors,
> please describe what you would like the software to do, and we'll
decide if
> it's feasible, and if so, what the level of effort would be (and
whether CBIIT
> will allow us to make the changes).
I will a description of what we want soon.
BZDATETIME::2013-05-16 10:42:35
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::3
(In reply to comment #2)
> (In reply to comment #1)
.
>
> I will a description of what we want soon.
I meant to say I will add a description of what we want soon.
Sorry.
^^^
Note that although William said back in the spring that we'd have a description of what is wanted "soon" we still don't have specs for this request. The request has been moved into the queue for the next release sprint, so we'll need those specs "soon." :-)
I revisited the code and confirmed that the existing software is built around the assumption that the disposition for a GP mailer will only be recorded in the tracking document once.
If possible, we will want to be able to mark a mailer as bounced, after the expiration date, and for the action to be recorded accurately. We currently use the mailer history to determine when to inactivate/block a record. For example, if a professional's email bounces, we research and find an alternative email. If the new email bounces too, we review the record for inactivation. Because we don't have a comprehensive way of capturing this information, we rely on manual lists and multiple reports to do this and it does take a lot of time to research and complete these tasks. I am hoping that it will be possible for you to record multiple mailer dispositions.
In the CDR status meeting we decided to solve the problem by changing the expiration time to 120 days.
Expiration period has been changed to 120 days on DEV. Ready for user testing.
Files affected:
r12004 gpmailers/cgi-bin/cgsd.py
r12004 gpmailers/cgi-bin/completed-gp.py
r12004 gpmailers/util/LoadGPEmailers
I have marked a number of records on DEV as bounced. A few of them should fall within the 120 days period but past the 60 days previously allowed. Do you need to run the cron job for me to verify the changes?
The previous expiration calculation was 30 days after sending of the mailer, not 60 days. The change will not affect mailers which had already expired. The cron job runs every night on DEV.
In that case, I really cannot test this until 120 days after generating new mailers.
or after 30days just to confirm that the program now allows more than 30 days.
Right, you can test after 30 day (not 120 days - if you wait 120 days you'll be in the same boat you're in now). If there are any that were created before today but less than 30 days ago, you'll be able to use those for testing once you've gone at least 30 days after the send date for those. You probably have such mailers in the production system.
I see that you, Margaret, and I got Klem's message, so I think we've confirmed the software on DEV is working the way we expected, as far as using the tester email addresses instead of the GP's address when we're on the DEV tier.
Right. I have generated a few more mailers to use for testing this issue and the other Gen Prof. issues. Thanks!
You should be able to verify these now, as more than 30 days have elapsed since the mailers were created.
Verified on DEV. I was able to mark a few mailers as bounced past the 30 days period.
I won't be able to verify this one until after 120 days so I will close it now and leave a comment after about 120 days.
Elapsed: 0:00:00.000642