Intake Stats | Add "issues elected into RAMP"

[abbyraskinUSDS]

AMO would like to see a breakdown of the # of issues elected into RAMP per day/week/month/FYTD.

Acceptance Criteria

• Show "Total Issues" section in Intake stats page, which represents total number of issues elected into RAMP based on contentions added to the resulting EP.

Technical Notes

This will require us to poll VBMS to check for contentions added. Will probably do this nightly job.

How to add a job: https://github.com/department-of-veterans-affairs/appeals-deployment/pull/1286

Additionally we need to figure out how to deal with EPs that aren't there or have been cancelled without adding contentions. I think for now we can just count them as zero issues.

The order of the sections should be:

Ramp Elections Received for < TIME > Total Higher Level Reviews Higher Level Reviews with Informal Conference Supplemental Claims Total without Opt In Total Issues Average Response Time Average Time since NOD Average Control Time

[shanear]

@sansb finshed running the job! Some issues with the script:

• RampElections don't start off with a non nil end_product_status, and thus will never be picked up by the job as is. We should either modify the script to include nil or have RampElections start off as PEND
• We have a case where updating one RampElection.update! is failing Rails validations: RampElection.where("receipt_date < notice_date").count
• We have a problem where we need high sensitivity to truly get all the claim statuses. We can use the user who originally completed the election to do this. We may want to store that on the ramp election too?

[sansb]

🏃‍♂️🏃‍♂️🏃‍♂️

Do you know how long it took? Would also be good to run it again and measure how long that takes. If this job takes an inordinate amount of time we might need to do some considering.

• I think we should modify the script to include nils. I'll send a PR.
• Not sure I understand- are you saying there's already some invalid data and our job is failing because that invalid snuck past the validation at some point in the past?
• That's a good idea. I looked into how we're doing this currently- https://dsva.slack.com/archives/C2ZAMLK88/p1522353060000195. What's the command you're running to auth with BGS? Maybe we can pair on this- I think it'll be tough for me to validate without prod access.

[shanear]

are you saying there's already some invalid data and our job is failing because that invalid snuck past the validation at some point in the past?

Yes. And i'm not sure I can correct that data, we may need to use some form of update! that bypasses rails validations

That's a good idea. I looked into how we're doing this currently- https://dsva.slack.com/archives/C2ZAMLK88/p1522353060000195. What's the command you're running to auth with BGS? Maybe we can pair on this- I think it'll be tough for me to validate without prod access.

Agreed. I think a start would be to start saving an established_by_user_id on ramp elections (& refilings for that matter) I will pair with you on using that information in the job.

[sansb]

@shanear couple questions-

1. we want to count all issues on all rampelections regardless of status, right? that is, we don't want to only look at issues where the EP is active, or something like that?
2. are we time-splitting this by receipt_date as with the other ones?

[sansb]

@shanear

re: Reviews where receipt_date < notice_date... that's bizarre (right?). Do we have any idea how that's happening? I feel like either one of two things are true here: 1. we are not OK with that condition being true and we need to find the cause and fix it, or 2. that's not an actual constraint and we should remove it.

My intuition here is that if we're about to start circumventing our validations, we should be careful about whether that's really what we want to be doing.

re: established_by_user_id, I can get a PR out for that as well. When you say user_id, do you mean OUR User model identifier, or is there another identifier somewhere specific to BGS?

[shanear]

we want to count all issues on all rampelections regardless of status, right?

Yes

are we time-splitting this by receipt_date as with the other ones?

Yes

re: Reviews where receipt_date < notice_date... that's bizarre (right?). Do we have any idea how that's happening? I feel like either one of two things are true here: 1. we are not OK with that condition being true and we need to find the cause and fix it, or 2. that's not an actual constraint and we should remove it.

Good point. So it's actually just one record that was causing the problem. I remember creating this record manually. Because somehow a valid RAMP election came in with a receipt date 1 day prior to the notification date. I just manually overrode the validation to fix it.

Also, since notification dates aren't even required anymore I'm thinking we should take out that validatation outright.

re: established_by_user_id, I can get a PR out for that as well. When you say user_id, do you mean OUR User model identifier, or is there another identifier somewhere specific to BGS?

Yes, our user model. It has all the BGS id's we need.

[sansb]

Sunil deployed the CloudWatch trigger. Now we should make sure the job is running successfully each night.

[shanear]

all but 7 seem to have been updated correctly.

irb(main):017:0> RampElection.active.where(end_product_status_last_synced_at: 20.years.ago..1.day.ago).count
[2018-04-16 18:36:17 -0400]    (7.5ms)  SELECT COUNT(*) FROM "ramp_elections" WHERE ("ramp_elections"."established_at" IS NOT NULL) AND (end_product_status NOT IN ('CAN','CLR') OR end_product_status IS NULL) AND ("ramp_elections"."end_product_status_last_synced_at" BETWEEN $1 AND $2)  [["end_product_status_last_synced_at", "1998-04-16 22:36:17.567566"], ["end_product_status_last_synced_at", "2018-04-15 22:36:17.567687"]]
=> 7

I fixed those 7 records. (see this comment for details: https://github.com/department-of-veterans-affairs/caseflow/pull/5087#issuecomment-381771608)

Eyeballing the stats seems to have the numbers work out. Going to close this one out