I have a requirement where users invoke a local action “Upload Bond”, through which they can upload a bond document along with capturing the Bond Received Date in a property.
Implementation Approach
I have created a concrete data class Data-UploadBond.
In this class, I created a view containing the following properties:
BondAttachment – for uploading the bond document
Bond - Attachment Category automatically created for attachment property
BondReceivedDate – for capturing the received date
In the work class, I created a BondsList property (Page List) with page definition Data-UploadBond.
This view is rendered as a repeating view within the main UI of the local action.
Observed Behaviour
When I launch the local action and upload documents:
The uploaded documents continue to be visible in the UI after submission.
However, the uploaded documents are not appearing in the Constellation Attachments widget (i.e., they are not being treated as case-level attachments).
Question
Is this behavior expected in Constellation when attachments are uploaded to a data page/list property instead of directly to the case context?
Correct, this is by design, else data level attachments would polute the attachments widget without the inline context of the data it was attached to. IF you want to show the attachments, just put the list in a partial view and case tab, then you can show the attachments inine with the BondsList.
@RameshSangili@MarcCheong
In the post activity of local action I am using pyLinkAttachmentToCase activity to attach the embedded attachments to the current case, but I am seeing there is no edit option available beside the documents. Is this behaviour expected?
The attachments added in Bond are read-only with no option to edit.
I would need to test this myself. However, just on replaying this in my head, I see a bigger problem. EVEN if you got this shown not as read only, now you have the data shown at the case level (out of context) and data level (in context).
IF you got this working, then what happens if I delete this from a case? You’d expect the system to delete this from the embedded data? What if that attachment was mandatory or needed? There is no workflow here, so we’ve circumvented the form logic.
Is this really the experience you’d want? Embedded data level attachments should be shown at embedded data level, if you want to modify your embedded data then that should be done in a form or optional action so you can apply the right logic. Personally, merging these concepts could create a poor UX or worse case a bug in process logic.
Gap for as long as I’ve been here with the standard widgets. Everything runs off of links to support linking one item (e.g. an attachment) to multiple other objects (e.g. a case). Simplest implementation was to only allow full removal of that item via the originating parent object.