CHI-3069: Backend contact create #730
Conversation
stephenhand
changed the title
…on field name more separate from the core logivc flow
| const adjustChatCapacity: AdjustChatCapacityType = require(path).adjustChatCapacity; | ||
| const body = { | ||
| workerSid, | ||
| adjustment: 'setTo1', |
There was a problem hiding this comment.
Why do we need to set capacity to 1 here? 🤔
There was a problem hiding this comment.
We always set it back to 1 on certain events. With backend manual pulling, instead of trying to track capacity, we just always have it set to 1, them set it to the value required to take an extra task when manually pulling or accepting transfers, then set it back to 1 again when we're done.
There is no issue with being 'over capacity' other than not being able to accept more tasks, so this is simpler than trying to track capacity against tasks
Also this logic isn't changed in this PR
| return false; | ||
| } | ||
|
|
||
| if (transferTargetType) { |
There was a problem hiding this comment.
Maybe this could reuse the hasTransferStarted method (functions/transfer/helpers.private.ts)?
There was a problem hiding this comment.
Not worth pulling it in for IMHO, when it's a lambda and we can import stuff properly then sure
|
|
||
| const prepopulatePath = Runtime.getFunctions()['hrm/prepopulateForm'].path; | ||
| const { prepopulateForm } = require(prepopulatePath) as PrepopulateForm; | ||
| await prepopulateForm(taskAttributes, contactForApi, formDefinitionsVersionUrl); |
There was a problem hiding this comment.
I think is harder to follow what is really happening here, cause prepopulateForm is mutating the given contact. Could we return a new object to make this explicit? (I will really appreciate that information being evident next time I'm around this code 😛)
There was a problem hiding this comment.
I won't make it a pure function because that makes it significantly uglier for deep objects and there's no practical benefit here since it's a brand new contact anyway.
I thought using 'populate' in the method name would have made the mutation effect clear, bad assumption on my part.
So the function still mutates but we reassign the output to a new variable to be clear. I also changed the method name to be more descriptive
There was a problem hiding this comment.
The reassignment is good enough, I don't mind it being pure as much as being explicit that the contact was transformed. Thanks for the change!
Description
enable_backend_hrm_contact_creationfeature flag.We are currently only using the static key encryption on the HRM call. We'll probably need something more secure for production
Checklist
Other Related Issues
None
Verification steps
Regression test new call & chat contacts, transfers and offline contacts
AFTER YOU MERGE
You are responsible for ensuring the above steps are completed. If you move a ticket into QA without advising what version to test, the QA team will assume the latest tag has the changes. If it does not, the following confusion is on you! :-P