I'm rather new to Alfresco and started to experiment with custom document types. Unfortunately, I wasn't aware about the one-way-type-change-restriction, leaving me now with quite a bunch of documents "locked" in some experimental document types.
Restarting from scratch is no option, so I would like to clean up by
reverting document types of particular documents back to "cm:content"
removing the custom document type from ACS
Now, I already learned, that reverting the doc-type isn't possible via the UI, because this is potentially harmfull. That is plausible, but no issue here. It's ok, if any properties linked to the custom type are lost during generalization back to cm:content.
As @afaust mentioned in a post, reverting the type is possible via the "low-level API". That may be a no-brainer for Alfresco geeks, but it quite a hurdle without any example or reference. Unfortunately, I haven't been successful yet in finding any further posts, hints or examples how to accomplish this.
So, any hints or comments to help with this challenge are very welcome.
Why not just copy the nodes to new instances of cm:content, then delete the old ones. That'll give you a chance to decide what to do with the properties that will no longer be present (delete them, use aspect-based properties, etc).
Once they are all gone (remembering to purge the trashcan of the deleted objects as well) you can safely remove the types from the model.
The low-level API I mentioned in the post you linked can be found in the Java NodeService for which there is documentation and some basic examples in the documentation. In there you will find the setType operation, which allows to change the type to any other type. This operation however does not however remove any existing properties which may now be superfluous / invalid on the node - this you would have to handle via removeProperty on the same service. Access to properties is done via the getProperties operation, which you would also have to use if you wanted to follow Jeff's recommendation of (selectively) copying those properties you want to keep onto a new node of type cm.content, which you would have to create via the createNode operation, since - as you found yourself - the copy operation in the CopyService would not be appropriate for the use case (it copies the type, and all properties, except those filtered by globally registered copy callbacks / behaviours).