deleted-U055HQT39PC
2024-12-31 13:09:38

Hey guys, made this chat for visibility. Just making sure we are good to go with the case type name change. NJ Sex Abuse SEC - DL - TC to NJ Juveline Hall Abuse SEC - DL - TC - DiCello Levitt Making sure everyone knows what to do to make this run smoothly.

deleted-U06C7A8PVLJ
2024-12-31 13:23:02

Here is what we came up with so far:

UPDATE public.financiallog SET typeofcase = 'NJ Juveline Hall Abuse SEC - DL - TC - DiCello Levitt' WHERE typeof_case = 'NJ Sex Abuse SEC - DL - TC'

This what was mentioned to me as well:

typeofcase, cocounsel, retainercode, parentcasetype, lead_source

So if query is missing those details lets see what we can do to gather those values?

Ryan (ryan@themedialab.agency)
2024-12-31 13:23:47

Edward, standby

deleted-U06C7A8PVLJ
2024-12-31 13:25:04

Thank you @Ryan

Ryan (ryan@themedialab.agency)
2024-12-31 13:31:37

UPDATE public.financial_log SET type_of_case = 'NJ Juvenile Hall Abuse SEC - DL - TC - DiCello Levitt' parent_case_type = 'NJ Juvenile Hall Abuse SEC - DL - TC - DiCello Levitt' client = 'DL', co_counsel = 'TC', lead_source = 'Dicello Levitt',

deleted-U06C7A8PVLJ
2024-12-31 13:32:12

Thank you Ryan. So running that should do the trick in the terms of updating it from NJ Sex Abuse SEC - DL - TC to NJ Juveline Hall Abuse SEC - DL - TC - DiCello Levitt? Just want to make sure before I do anything with pgadmin

Ryan (ryan@themedialab.agency)
2024-12-31 13:32:51

It should, bt use a SELECT ** to validate your query, get your counts, do your pre-update numbers of what you are updating, all that is part of the "cleaning and preparing your production data updates".

Ryan (ryan@themedialab.agency)
2024-12-31 13:33:09

But yes, that withyour. WHERE clause on the old typeofcase name.

deleted-U06C7A8PVLJ
2024-12-31 13:33:18

Gotcha to see how many counts there are and then when we do the update it should equal to same # basically

deleted-U06C7A8PVLJ
2024-12-31 13:33:39

Will get the counts first

deleted-U06C7A8PVLJ
2024-12-31 13:53:58

Okay show I got 19 in pgadmin however LR is showing 35 so we are missing 16 (I haven't updated anything yet) however I am going to send some screenshots of this

deleted-U06C7A8PVLJ
2024-12-31 13:54:55

So if I were to perform update it looks like only 19 out of 35 will be "updated". Need to figure out first where to get all 35

deleted-U055HQT39PC
2024-12-31 14:23:30

ah ok. got it

deleted-U06C7A8PVLJ
2024-12-31 14:38:49

Shall we trouble shoot to find the missing 19 or okay to just update as is?

Ryan (ryan@themedialab.agency)
2024-12-31 15:27:47

@deleted-U06C7A8PVLJ , get the lead ids, make sure they all get changed status to final billable, bulk change them and they should appear in morning.

deleted-U06C7A8PVLJ
2024-12-31 15:37:56

Copy that ! To confirm you are referring to changing them in PGadmin to a final billable correct? Or do you mean in LR?

deleted-U06C7A8PVLJ
2024-12-31 15:42:20

SELECT ** FROM public.financiallog WHERE lrleadid = 595264 ORDER BY typeofcase,lastname ASC;

deleted-U06C7A8PVLJ
2024-12-31 16:28:56

Update: I was able to identify the 16 that were not reflecting in PGadmin and I changed them to a billable status and back to the status that they were "so that it triggers". Now if I were to run a "test" in TIP-Py311-GenerateFinancialLogPy311-9YN38SeLubUn in AWS that should re-run it so I can see those changes today instead of tomorrow morning right? @Ryan

Ryan (ryan@themedialab.agency)
2024-12-31 16:29:35

You could run it now, or wait

deleted-U06C7A8PVLJ
2024-12-31 16:30:23

Oh okay I shall run it now and from there if PGadmin says 35 then that would match LR since LR has 35.

Finally I would need to run this:

UPDATE public.financial_log SET type_of_case = 'NJ Juvenile Hall Abuse SEC - DL - TC - DiCello Levitt' parent_case_type = 'NJ Juvenile Hall Abuse SEC - DL - TC - DiCello Levitt' client = 'DL', co_counsel = 'TC', lead_source = 'Dicello Levitt',

To update it from:

NJ Sex Abuse SEC - DL - TC to NJ Juveline Hall Abuse SEC - DL - TC - DiCello Levitt

Correct?

Ryan (ryan@themedialab.agency)
2025-01-01 08:56:45

Add the WHERE clause but that is your SET statement.

deleted-U06C7A8PVLJ
2025-01-02 08:44:21

That makes sense. Thank you Ryan.

deleted-U06C7A8PVLJ
2025-01-02 08:45:03

Also, I can see that it went from 19 to now 31 which is better but still missing 4 leads in PGadmin. I think it may because those 4 are not in a billable status which is strange since I put them into a billable status in LR and then back to non billable status (since they still need to be worked on). That worked for 12 of them which is how it went from 19 to 31 but the other 4 it didn't out of 35

deleted-U06C7A8PVLJ
2025-01-02 08:46:02

So I may need to try the other method and find those 4 individually in PGadmin and have those changed and then use the query above along with the "where clause"

Ryan (ryan@themedialab.agency)
2025-01-02 08:50:00

We will solve, send me the 4 lead IDs that are missing in the SQL.

deleted-U06C7A8PVLJ
2025-01-02 08:56:58

Thank you @Ryan. I believe it may just be these 4: 591757 591763 598976 598987 Since they are in referral accepted - NJ Sex Abuse SEC - DL - TC

image.png
Ryan (ryan@themedialab.agency)
2025-01-02 09:18:17

@deleted-U06C7A8PVLJ, the rawstatusreport table's field for these 4 were set to "Referral Accepted", to my knowledge that is not Billable Post Retainer status, if it is, we need to update our Sheet, our IO Table and our AWS Lambda code @James Turner, please advise. But these 4 are getting imported now into fin_log.

deleted-U06C7A8PVLJ
2025-01-02 09:19:31

Thank you @Ryan Yeah those are not a billable status. I had switched those 4 into a billable status, left it for a min or two then switched it back to Referral Accepted status to see if it will "trigger" it in PGadmin for the next run since that's what worked for the other 12 but not for those 4 but wondering if it is because it went back to "referral accepted" status.

deleted-U06C7A8PVLJ
2025-01-02 09:19:38

But thank you for adding into fin_log

Ryan (ryan@themedialab.agency)
2025-01-02 09:19:57

Yeah, weird it didn’t register in LR

:eyes_3d: deleted-U06C7A8PVLJ
Ryan (ryan@themedialab.agency)
2025-01-02 09:29:47

@deleted-U06C7A8PVLJ

image.png
deleted-U06C7A8PVLJ
2025-01-02 09:32:42

Thank you Ryan ! and from there I am assuming we just gotta change the status in PGadmin to a "billable" status and it will be good from there

Ryan (ryan@themedialab.agency)
2025-01-02 09:33:36

Yes, I did the hack in rawstatusreport and re-ran Lambda, poof, they were there

:cool_doge: deleted-U06C7A8PVLJ
deleted-U06C7A8PVLJ
2025-01-02 09:37:47

That makes sense

deleted-U06C7A8PVLJ
2025-01-02 09:59:40

All 35 is showing and matches LR now which we can now do the name change in PGadmin :meow_party:

image.png
Ryan (ryan@themedialab.agency)
2025-01-02 10:00:08

Boom.

🙌:skin_tone_2: deleted-U06C7A8PVLJ
deleted-U06C7A8PVLJ
2025-01-02 10:05:35

I believe this should be the query to run in order to change from: NJ Sex Abuse SEC - DL - TC to NJ Juveline Hall Abuse SEC - DL - TC - DiCello Levitt Correct?

image.png
deleted-U06C7A8PVLJ
2025-01-02 12:59:43

Also do you want that query above to be ran from "tip_master" database ? @Ryan

image.png
Ryan (ryan@themedialab.agency)
2025-01-02 13:25:13

Yes Edward, that’s the Production DB

deleted-U06C7A8PVLJ
2025-01-03 10:33:20

Thanks. Posting for reference purposes that NJ Sex Abuse SEC - DL - TC has been changed to NJ Juvenile Hall Abuse SEC - DL - TC - DiCello Levitt: Both are 35 (LR and in PGadmin)

image.png
🙏:skin_tone_4: Ryan