1

I've been tasked with updating a legacy Notes application - I'd rather do basically anything else, but such is life. As per the API, I should be able to update a rich text field if the data is in format

FieldName: { contentType: 'text/html', data: newData, type: 'richtext' }

(serialized to JSON, of course)

But what happens is that the original RT field gets replaced by three MIME Part fields (with the same name, containing what you'd expect, "Content-Type: multipart/mixed", "boundary" and so on), and "newData" gets stored in a $FILE attachment. And also few MIME-specific fields get added to the document ($MIMETrack, $NoteHasNativeMIME, MIME_Version).

Now this certainly wouldn't be the first time that Notes documentation doesn't match actual functionality, but I was wondering if anyone has been successfully able to do this? Alternatively, any other way to update an RT field via AJAX (preferably with HTTP PATCH)?

EDIT: upon further inspection, this seems to be a configuration issue. I tried doing a GET from a document with an RT field (that contains the text "testing rt field", submitted via a regular web form), the expected result would be according to the API

"FieldName": {
"contentType":"text/html",
"data":"testing rt field",
"type":"richtext"
}

but instead what is returned is

"FieldName": {
"type":"multipart",
"content": [
{
"contentType":"multipart\/alternative; Boundary=\"0__=4DBB0A82DFA47A268f9e8a93df938690918c4DBB0A82DFA47A26\"",
"contentDisposition":"inline"
},
{
"contentType":"text\/plain; charset=US-ASCII",
"data":"testing rt field",
"boundary":"--0__=4DBB0A82DFA47A268f9e8a93df938690918c4DBB0A82DFA47A26"
},
{
"contentType":"text\/html; charset=US-ASCII",
"contentDisposition":"inline",
"data":"<html><body><font size=\"2\" face=\"sans-serif\">testing rt field<\/font><\/body><\/html>",
"boundary":"--0__=4DBB0A82DFA47A268f9e8a93df938690918c4DBB0A82DFA47A26"
}
]
}

(sorry for the formatting)

So I'm guessing there is a problem with our Domino configuration somewhere. Where, I have no idea, any tips would be greatly appreciated.

wutnau
  • 11
  • 3
  • FWIW, the server is running Domino 8.5.3 UP1 - and updating to 9.x is not really an option. – wutnau Aug 15 '16 at 11:01
  • The documentation also states that: "Attempting to create or update a rich text field with attachments or embedded objects, or references to attachments or embedded objects, returns error 400 (Bad Request).." Rich text and MIME aren't 100% compatible, so you may expect some issues there. Is there any reason why you use the (new) API, and not a Java or LotusScript agent to update documents? – D.Bugger Aug 16 '16 at 09:34
  • newData is valid html? – D.Bugger Aug 16 '16 at 09:37
  • The intention is not to do anything with MIME or attachments, that is just an unintended side effect. As to why we are using the API, it makes many REST-operations just so easy - up until now. There is this one field where we felt "we'll never hit the 32k field limit" (a string containing serialized JSON) - as you probably have already guessed, we've hit that limit and the field should be converted to rich text to get around the limitation. Whether newData is valid HTML or not seems to have no effect on what happens. – wutnau Aug 16 '16 at 10:28
  • "submitted via a regular web form": I assume that Domino doesn't create a rich text field when it's a web form, but only MIME. Please check that this document has indeed a rich text field and not a MIME type field. Can you create a document with a real rich text item using the Notes client? In any case: rich text and mime type fields should both be seen as rich text fields by Notes. – D.Bugger Aug 16 '16 at 14:49
  • And check this: https://www.ibm.com/support/knowledgecenter/SSKTMJ_8.5.3/com.ibm.help.domino.admin85.doc/H_CONFIGURING_HOW_DOMINO_CONVERTS_INBOUND_MIME_MESSAGES_TO_NOTES_RICH_TEXT_STEPS.html – D.Bugger Aug 16 '16 at 14:49
  • A similar issue: http://stackoverflow.com/questions/31273275/convert-mime-to-richtext but I don't know if you have the equivalent of a session in your JavaScript code that uses the API. – D.Bugger Aug 16 '16 at 14:59
  • Well, at least when I look at a test document (trying to nail the process down before I start messing around with actual data - a replica even then of course) from the Notes client, the field is Rich Text, yet the output is as above. When I update the field (or create a new one), it turns into those three MIME Part fields. Thanks for the suggestions, but still no dice. I guess I'll have to take the agent route, haven't been able to find anything related to this. – wutnau Aug 16 '16 at 15:55
  • If you are using 8.5.3 UP1, I don't see how your GET request returns multipart data as mentioned in your edit. The multipart data type was added in Domino 9.0. Please confirm the version of Domino you are running. – Dave Delay Aug 16 '16 at 20:08
  • According to Domino Administrator it is running 8.5.3FP6, and according to instructions in http://www-01.ibm.com/support/docview.wss?uid=swg21590428 UP1 should be installed correctly too (20111208-0717 is included in the output of each command) – wutnau Aug 17 '16 at 09:19
  • ...but I just tried adding multipart=false to the GET and lo and behold, the output is as expected. Not even going to try to explain it (not the server admin) nor do I really care, but THANK YOU! I think I can take it from here. – wutnau Aug 17 '16 at 09:42
  • That's good news. Now that we're on the same page, I created an answer. By the way, even though you can use the older, single part format, I recommend using multipart in 9.0 and beyond. – Dave Delay Aug 17 '16 at 12:34

1 Answers1

1

In Domino 8.5.3 UP1 the data service represented rich text fields as one HTML part ("type": "richtext" as described in the 8.5.3 doc). This had some severe limitations. For example, you couldn't create a rich text field with embedded images and attachments.

Since Domino 9.0 the data service represents rich text fields as multiple parts ("type": "multipart" as described in the 9.0.1 doc). However, you can still PUT and POST the old rich text format, and you can GET the old format by specifying multipart=false in the URL. In other words, the original poster seems to be using Domino 9.0 and it is working as expected.

Dave Delay
  • 1,292
  • 8
  • 12