It is currently not possible to access the three components of an attachment (attachmentName, attachmentData, attachmentOrigSize) except through a set-fields via webservice action. It should be possible to address these three components from other set-fields actions as well.
This has become an urgent issue for us since upgrading from 7.6.04 to 8.1.01.
The reason is that prior to 8.1.01, if an attachment object had an 'attachmentName' attribute containing a trailing line or carriage return, the mid-tier would filter this when the user attempted to download or view the attachment. Since 8.1.01, this behavior has been changed. The carriage or line return is now replaced with an underscore ("_") character.
This means an attachment name of: 'Readme.TXT' (with a line return tacked on the end) becomes 'Readme.TXT_'. This means when the user downloads or otherwise attempts to view the attachment, windows (or whatever OS they're using) will no longer recognize the MIME type and the user gets the "I don't know how to deal with this file type" error.
So how do you even get attachments where 'attachmentName' contains a line return? Good question!
It's happening for us via an external webservice integration (we call the webservice to retrieve attachments, and the external webservice returns a value with a trailing carriage return on the XML element that's mapped to attachmentName). For testing purposes, I've also found that it is possible to create such attachments explicitly via the API.
What makes this absolutely infuriating is that there is absolutely no way to fix the problem (in workflow anyhow).
It's easy enough to write some workflow to filter the carriage returns from the filename, but there is not any way to update the attachment file name. Likewise, if we were to simply take the 'attachmentName', 'attachmentData', and 'attachmentOrigSize' XML elements and write them into temp fields, we STILL can't create an attachment because you can't address those three components from a regular set-fields action.
About the best I could do would be to set up my own webservice to set the attachment. Pull the three attachment components into tmp fields, then call my own webservice to update the attachment filename. For various reasons, I refuse to do that. Primarily because it is a completely asinine thing to do, which will undoubtedly cause still more problems.
Actually, I take it back. That is not the most infuriating part of this.
The most infuriating part of this is that BMC support sent me HERE to this forum to make an "enhancement request", after they BROKE existing functionality with no workaround.
And so here's the "enhancement request" which I am absolutely certain will be completely ignored.
Guess it's time for me to dig into the DB and see if I can find a way of brute-force changing the attachment filename on my own.