Closed rjharmon closed 13 years ago
Oops, looks like a regression that I let in when I refactored to handle arrays. The other two cases use arrays of objects that do respond to #soapify_for
.
I can see 3 solutions to the problem.
1) Add String#soapify_for
class String
def soapify_for msg
msg.add 'entry', self
end
end
However, I'm not sure if 'entry'
will be acceptable to the JIRA XML parser. If not, then the method will have to take a second optional parameter somehow.
2) Make Array#soapify_for
check if an object responds to #soapify_for
before sending it, and if not then it just calls add on the msg
object.
3) Revert #add_attachments
to the jiraSOAP 0.8.6 behaviour of handling the soapifying process itself. :(
I prefer the first solution for run time performance reasons, but other APIs in the future would have to be careful if they contain an array with an object that does not respond to #soapify_for
.
In either case, I can't test that this works right now, so could you try it out for me?
I copied the code from 0.8.6 and it works fine.
I'd dug into the problem on my own in the meantime, and I was hoping to simply pass an array of Attachment objects (renamed from AttachmentMetadata), and have add_attachments take care of converting that list of attachments to the shape of message needed by JIRA, including base64'ing it - much more rubyish.
The code from 0.8.6 demonstrates pretty clearly how to do that, if it works for you.
WDYT?
I got it working and I've made a pull request. We can resume discussion there, I guess.
Any suggestions on how to soapify these string-arrays?
addAttachmentsToIssue