Open Ritesh717 opened 2 years ago
@ssarap - This is needed for KCH project. They have requirement for attachments to be sent over to native systems as part of data. So to get the file href we need the relational data. Can this be prioritized?
@karthmoh FYI
@ssarap For now, we have identified a workaround - to download the file ( using File download action) using the id of the attachment and then accessing the fileHref property. But this will add one more task every time a file is uploaded. So, we need this to be prioritized so that we can make these changes before KCH goes live.
Thanks Karthik.
@karthmoh is the intention here that you would include the 'File' model as the related instance, so that you then extract the contents directly from that without a separate task? In the case of KCH, do you have an idea of volumes? I understand they only have a few hundred cases a month, and so you're talking a few k tasks a year for the extra step at the moment?
Hi @duncancasemore
Yes, the current case model does not have a direct foreign property to the case attachment model, instead, that is added to the form as a relationship. The case attachment model has a reference to the case model.
When a case is raised with an attachment, caseId is used to retrieve the attachments from the case attachments model where the fileHref or any other fileURL properties are not returned. So, there needs an additional step(or steps in case of multiple attachments) to use this id to download the file(s) and act on it.
This is the report we have for the month of Nov 2021, on a day by day basis. This report gives the number of cases created or updated on a day.
Based on this, the volume might be on the higher side, if most of these actions are performed through Applaud. Please review and share your thoughts on this.
Thanks, Karthik.
@karthmoh interesting ok. So actually you want to include the CaseAttachment model as a relationship, then in Workato loop through those case attachments and download the file contents?
You're right: those volumes are a lot higher than I thought. Still, I guess this is only needed when CREATING cases via Applaud, which should be a (much?) smaller number...
This is going to take more time, hence moving this to icebox for now. Will pick this only if really required by the customer.
Summary
Acceptance Criteria
Wireframes and mockups
Search action
Notes
Developer Testing
Requestor: leave this section blank Developer: complete this section during commit/pull request
Positive testing:
Add all the things that you have checked whilst completing this story here, it should be written in a non-technical way, and a lot of this can probably be taken from the acceptance criteria, here are two different examples:
Negative testing:
Here you list the things you have checked where your code needs to show an error, handle unusual/bad input/config gracefully, or may impact separate features that use or depend on the same code. Pause and think -- they may not be obvious! Examples:
e2e test links and description: