Content Type cannot be changed for Office documents, if Document-CT has customized Forms, in regular SharePoint Document Libraries

[EinmalIM]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

not applicable

Developer environment

No response

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• browser version
• SPFx version
• Node.js version
• etc

Describe the bug / error

This seems like a bug how SharePoint handles Office documents: we cannot change a Microsoft Office documents content type in a SharePoint document library if the content type has a customized form. This happens for docx and xlsx but not for txt or pdf files.

You can take the following JavaScript code in a browsers dev tools console when you are in the allitems.aspx view of such a SharePoint list to customize the form:

`const spWebUrl = _spPageContextInfo.webAbsoluteUrl; // assuming to be on a SharePoint AllItems.aspx list-view page
const docLibId = _spPageContextInfo.listId; // assuming to be on a SharePoint AllItems.aspx list-view page
const testCtId = '0x010100B68D7A00400FB34BA1A31C9ABBB97168'; // GET THE ID OF THE DEFAULT-CONTENT-TYPE ("Document") FROM THE LIBRARY SETTINGS PAGE
const formUrl = _spPageContextInfo.webServerRelativeUrl + '/SitePages/TestForm.aspx'; // custom form location

// to switch to custom forms, uncomment the following line:
setFormsForCT(spWebUrl, docLibId, testCtId, formUrl, formUrl, formUrl);
// check the console and network tab output whether the operation was successful

// to restore standard forms, uncomment the following line:
//restoreFormsForCT(spWebUrl, docLibId, testCtId);

async function setFormsForCT(webUrl, listId, ctId, dispFormUrl, editFormUrl, newFormUrl) {
await fetch(${webUrl}/_api/web/lists('${encodeURIComponent(listId)}')/contenttypes('${encodeURIComponent(ctId)}'), {
method: 'POST',
headers: {
'Accept': 'application/json; odata.metadata=minimal',
'Content-type': 'application/json; charset=utf-8',
'X-HTTP-Method': 'MERGE', // updating
'IF-MATCH': '*',
'X-RequestDigest': _spPageContextInfo.formDigestValue, // assuming valid and defined
},
body: JSON.stringify({
"DisplayFormUrl": dispFormUrl,
"EditFormUrl": editFormUrl,
"NewFormUrl": newFormUrl
}),
});
}

async function restoreFormsForCT(webUrl, listId, ctId) {
return setFormsForCT(webUrl, listId, ctId, "", "", "");
}`

Steps to reproduce

1. Create a new document library in a SharePoint site
2. activate Content Types, add any second Content-Type (e.g. Picture)
3. upload a blank Excel or Word file into the library,
4. change the Forms of the default Content Type (Document, see sample code below)
5. attempt to change the document's content type - the change is not effective

Expected behavior

We expect that the content type gets changed, no matter what type of file is stored in a document library.

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[EinmalIM]

Hi Vesa, any hints if this will get fixed?

[github-actions]

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.