Updating a Lotus Notes rich text field via AJAX/Domino Data Service API

Question

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.

FWIW, the server is running Domino 8.5.3 UP1 - and updating to 9.x is not really an option. — wutnau
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
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
"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

Dave Delay Dave Delay · Accepted Answer · 2016-08-17T12:26:01

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.

Updating a Lotus Notes rich text field via AJAX/Domino Data Service API

1 Answers