-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DDLS-360 Add new clients found in the LayDeputy csv #1771
Changes from all commits
9c938f8
dd932af
10a7ab2
b1e972e
355bfcc
4df2543
d1f7a14
683033b
0718072
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -60,4 +60,47 @@ public function findByCaseNumber(string $caseNumber) | |
->getQuery() | ||
->getResult(); | ||
} | ||
|
||
public function getNewClientsForExistingDeputiesArray(): array | ||
{ | ||
$conn = $this->getEntityManager()->getConnection(); | ||
|
||
$newMultiClentsQuery = <<<SQL | ||
SELECT | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've tested this query locally, and it does return clients that are already created. |
||
pr.client_case_number AS "Case", | ||
pr.client_lastname AS "ClientSurname", | ||
pr.deputy_uid AS "DeputyUid", | ||
pr.deputy_lastname AS "DeputySurname", | ||
pr.deputy_address_1 AS "DeputyAddress1", | ||
pr.deputy_address_2 AS "DeputyAddress2", | ||
pr.deputy_address_3 AS "DeputyAddress3", | ||
pr.deputy_address_4 AS "DeputyAddress4", | ||
pr.deputy_address_5 AS "DeputyAddress5", | ||
pr.deputy_postcode AS "DeputyPostcode", | ||
pr.type_of_report AS "ReportType", | ||
pr.order_date AS "MadeDate", | ||
pr.order_type AS "OrderType", | ||
CASE WHEN pr.is_co_deputy THEN 'yes' ELSE 'no' END AS "CoDeputy", | ||
pr.created_at AS "MadeDate", | ||
pr.hybrid AS "Hybrid", | ||
pr.deputy_firstname AS "DeputyFirstname", | ||
pr.client_firstname AS "ClientFirstname", | ||
pr.client_address_1 AS "ClientAddress1", | ||
pr.client_address_2 AS "ClientAddress2", | ||
pr.client_address_3 AS "ClientAddress3", | ||
pr.client_address_4 AS "ClientAddress4", | ||
pr.client_address_5 AS "ClientAddress5", | ||
pr.client_postcode AS "ClientPostcode" | ||
FROM pre_registration pr | ||
LEFT JOIN dd_user u ON pr.deputy_uid = u.deputy_uid::varchar(30) | ||
LEFT JOIN deputy_case dc ON u.id = dc.user_id | ||
LEFT JOIN client c ON dc.client_id = c.id | ||
WHERE c.case_number != pr.client_case_number | ||
SQL; | ||
|
||
$stmt = $conn->executeQuery($newMultiClentsQuery); | ||
$result = $stmt->fetchAllAssociative(); | ||
|
||
return $result; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would need to disable the softdeletable filter here before running the query.
The reason being is that when we probably should include the discharged clients in the check so that if they appear in the CSV for this particular deputy, they aren't recreated again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that we're going for strings as that's whats on sirius for deputy uid I'd do the cast the other way round and cast the bigint (that we're ditching eventually) as a string (or varchar or whatever it's called in database language) instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it just a case of removing the softdeletable filter Gugs on line 103? I think the SQL should bring back all the discharged ones fine but then the filter gets rid of them right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you have to disable it before the query, run the query (it will now ignore the filter), and then enable it again afterwards so it doesn't affect any other queries afterwards.
Thinking about it, it's not the greatest implementation because if you've got a query that is going to run for a long time then the filter is disabled for a long time too. Which means there's a higher chance some other query in the app is going to be running and that might be expecting the filter to be enabled.