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.

unpublish

tmath1

how do you unpublish from the remote server? We publishing items to a remote runtime environment. When we delete, it removing items from both the authoring and runtime environment, but is it possible to unpublish from the authoring environment so that the asset is removed only from runtime?

Find more posts tagged with

Comments

tmath1

please refer to this post…

Re: How workflow working with deleted tree structure and ass

Postby qsdmv » 26 May 2011, 21:33

tmath1

Sorry I meant to add this post url:

http://forums.alfresco.com/en/viewtopic.php?f=52&t=38483

bremmington

Sorry - this is still on my list of things to do. I'll try my best to get it sorted for the next community release.

tmath1

Thanks Brian. Do you have an eta on the next community release?

tmath1

Hey brian,

Did you get to look into this anymore?

bremmington

As it happens, the code for this is currently sitting in my sandbox waiting to be tested and committed. I still hope to get it into the first 4.0 community release (should be end of September / beginning of October, I think).

tmath1

any suggestions on how to accomplish this 3.4.4 enterprise? I'm about to release to our internal contributors.

tom

bremmington

The class that causes the main problem is called TransferManifestNodeFactoryImpl. This is the class that takes a noderef and generates an object that is later rendered into XML for transferral. It implements the basic interface TransferManifestNodeFactory and, as with most things, can be replaced with an alternative implementation via Spring if desired.

If you'd like to do that, then the area of logic that you should consider changing is in the first 20 lines or so of the createTransferManifestNode method in the out-of-the-box implementation. This is trying to work out whether it should be creating a TransferManifestDeletedNode object or a TransferManifestNormalNode object.

I suggest that you alter this logic in a custom implementation such that if it is given a noderef that is in the archive store then it assumes immediately that it should create a TransferManifestDeletedNode object. Otherwise it follows the same logic as the current implementation.

If that change was made then you could force the removal of a node on the receiving side by "faking" an archive store noderef based on the actual noderef. That is to say that if you want to force the removal of the node "workspace://SpacesStore/8d02b691-ecab-49b6-98d3-e7dd991ddd54" on the destination then you would actually put this noderef into the transfer definition: "archive://SpacesStore/8d02b691-ecab-49b6-98d3-e7dd991ddd54".

Does that make any sense? Come back to me if not, and I'll have another stab at explaining it.

Just for information, the approach that I've taken to resolving this in the 4.0 stream is different to what I've described above. I have added an additional set of noderefs to the TransferDefinition class that is used to hold nodes that are to be removed from the target repo. The TransferManifestNodeFactory interface now allows a flag to be set that indicates that the caller wants to force a removal of the specified node. I think this is neater, as it removes the need to rely on the archive noderef as an indicator.

tmath1

Thanks Brian. I think I understand. We'll try this out and get back to you.