Attachments on a process instance: some thoughts
Here's a couple of thoughts about attachments, ie where you need to attach some binary document to a process instance:
First, the requirement I have is to be able to attach an arbitrary number of documents to the process. I don't seem to be able to do that, though I notice I can do precisely that to a forum post like this one. The current demo I'm building requires a vague number of attachments. They suggested 10 for a maximum. I find setting up each field to be pretty tedious (with the assignments, datainput set etc) so I talked them down to 5. But I know what they really want is to be able to attach as many as they want. Sometimes it will be 6, sometimes 11. Has anyone considered this? Has it been there all along and I missed it? Are there reasons for doing the one-field-per-document approach that are more attractive than an arbitrary number? I can understand the situation where there must be, say, a purchase order document, and you make it required to ensure it is there. But maybe both would be good?
I notice we can now add comments to a task, which I got excited about because I thought at first it was to the process instance. I see the need for comments on tasks, but I see just as much need for comments on process instances. I currently have a comments field, but that doesn't capture the history, user or date stamp like comments would. Comments aren't attachments, but I put this here because comments (on tasks) do have an arbitrary number.
The second thing on attachments is an observation about the kie-deployment-descriptor.xml file. Since 6.2.CR4 there is an editor in the WB to help us get the format right. I can see the need for it because there are strict and non-obvious requirements around whitespace on this file. However I'm finding it un-useable. Perhaps it just needs some docs to explain what I should be doing, but when I want to change it I pull it from the repo, edit it with a text editor and push it back. This works for me, but it seems a waste of someone's effort.
I'll end with pointing out that I do like that we can add our own implementation. At the moment I'm using the OOTB handler and it seems fine, though I'll implement something that stores the docs in database blobs when I get to it. If anyone is looking for them the OOTB handler stores the attachments under .docs/... in my case the .docs dir was created under my Wildfly/bin dir. They are stored in a file structure.
