OTCS REST API - Define Document Mime Type?
Hi, is is possible to define a MIME type for a document when using the REST API? We are using Content Server version 16.2.3.
The reason for the question is that when we add an Office document to Content Server using the REST API, the MIME type is showing the correct value. However, we are unable to edit the document. When changing the MIME type within the document Properties -> Specific -> MIME Type to something other than the current MIME type, and then change it back to what it was originally set, the document then becomes editable.
Here is the Java code that performs the document upload operation:
MultiPart multipartEntity = new FormDataMultiPart().field("type", type).field("parent_id", parent_id).field("name", name);
if (row.getValue().get("file") != null) {
String tempFileName = getConversion().convert(row.getValue().get("file"), String.class);
File tempFile = new File(getMetadata().calculateTempFolder(), tempFileName);
FileDataBodyPart filePart = new FileDataBodyPart("file", tempFile);
filePart.setContentDisposition(FormDataContentDisposition.name("file").fileName(name).build());
multipartEntity = multipartEntity.bodyPart(filePart);
}
return getService().post(target, Entity.entity(multipartEntity, multipartEntity.getMediaType()));
Thanks in advance.
Tagged:
0
Comments
what errors do you get in the UI / logs when you try and edit the uploaded document ?
There are no errors present as the option to edit is just not there. The only options are open, download, and comments. I can even view the document as Web Page. Here is the output when the document is added:
There are no errors present as the option to edit is just not there. The only options are open, download, and comments. I can even view the document as Web Page. Here is the output when the document is added:
I was looking for the logs from the Content Server side after the upload on the screen where the Edit option does not immediately appear. Looking at the code there are some checks that happen before the button is shown. The code is in $WebEdit.WebNodeCmds.Edit.IsEnabled
Apologies, I cannot find the that specific code you are referring to. I tried looking through the CGI and thread logs and found no reference to that specific code. Can you provide additional information as to where I can find it? Thanks.
EDIT - additional info: I have all Content Server logging set to TRACE.
The logs at the time of the "issue" may show what was the cause of the problem. The reference to $WebEdit.WebNodeCmds.Edit.IsEnabled was to show you where in the Developer SDK you can find the code that controls the display, so if you had the SDK you could debug directly.
We are not using the SDK, so I hope these logs provide some insight.
CGI Log:
Thread log:
I have some additional information: when adding a new version to that document that we were previously unable to edit, the MIME type is defined and the document is editable. Here are the logs from that process:
CGI:
Thread:
Looking at the log, for the first upload you have :
file_filename = 'file1131425378715884024'
for the second, add version, you have :
03/07/2019 10:54:41 INFO file_filename = 'TESTING Document.docx'
I suspect this may be causing an issue with either the setting of the MIME Type on load or the display of the EDIT button - which may be checking for a known file ext.
Can you retest using a correct filename and ext in the first case ?
Also worth reading the OT doc on MIME Type Detection - https://knowledge.opentext.com/knowledge/cs.dll/kcs/kbarticle/view/KB489279
The code has been fixed so that the filename field correctly matches the name of the file. However, we are still unable to edit. Here are the logs:
between each step, what do you see in DVERSDATA for the document ?
Here is the DVERSDATA for the WordDocument-9-test.docx document:
And after adding a new version this is the result of the DVERS Data: