nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Revert document type change

joergd

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.

I've no issue with solving this challenge programtically (basic JavaScript and good Java skills are present), but it's hard to decide wich of the many APIs to follow here.

So, any hints or comments to help with this challenge are very welcome.

Find more posts tagged with

Alfresco Content Services

Comments

jpotts

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.

joergd

Hi Jeff, thanks for responding.

That sounds like an interesting approach, that would be just as good. However, that "copy the nodes to new instances of cm:content" leaves me with almost the same challenge. I simply don't know how...

I browsed through the different APIs, but so far it didn't hit my eye how to tackle that. The copy method, just copies the document to another folder, but has no effect on the type!?

Could you please sketch the essential portion of your approach, or point me to an example, that contains such a procedure?

afaust

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).