How workflow working with deleted tree structure and asset?

[qsdmv]

Hi,

I have used workflow to publish tree structure and asset by update, add new sub-tree and new content without problem. But remove content or tree didn't work. The key question is how do we drop the deleted nodes (tree node or asset node) into the queue. As long as we can drop into the publish queue, we have no problem. But once the asset or tree node deleted, there is no way to start workflow which mean that there is no way to drop the nodes into the publish queue. Hopefully someone gives me insights.

Thanks in advance.

[bremmington]

Take a look in the WebAssetAspect class (org.alfresco.module.org_alfresco_module_wcmquickstart.model package). The init method registers a behaviour that hooks on to the "BeforeDeleteNode" policy, and the beforeDeleteNode method places the node onto the publishing queue using the enqueueRemovedNodes operation on the PublishService. This means that when a node that has the webasset aspect is deleted it is automatically added to the queue. This causes it to be removed from live.

You should be able to use a similar technique to do want you want to do.

[qsdmv]

Thanks. Further, what if I want to unpublish a content from live instead of delete.

Actually This is the case we often have:

1). I have a new content done. I would like to publish it (no problem).
2). Ooops, I am not supposed to publish today. It should be published tomorrow. In this case, I need to keep this content from edit site, and delete from live. How can we do this?  (Remember: edit and live site is not on the same box. The content owner can only access edit box. For live box, only thansfer service and surf application can access).

Thanks,

[bremmington]

The idea would be quite similar to what I described earlier, but rather than hooking into the BeforeDeleteNode policy you would want to write an "unpublish" action that would call the same operation on the PublishService ("enqueueRemovedNodes"). You might want to look at the class "WebPublishAction" and make use of most of the code there. At the end of the executeImpl method in that class there is a call to PublishService.enqueuePublishedNodes. In your class you'll want to replace that with a call to PublishService.enqueueRemovedNodes.

You could add your new unpublish action onto the Share interface in a way that is similar to a response I gave to someone else a while ago who wanted to add a "publish now" action to WQS in Share.

Hope that helps.

[qsdmv]

I feel like that it is possible to implement delete but unpublish. Transfer service is kind like sync process:

1). If you delete the node from edit site and add this node to the queue, then transfer service is going to sync both edit site and live site. If this node in the queue and crawler can find, it will also delete it from live site if it delete from edit site;

But unpublish the node just like this node never publish before. It ONLY exists on edit site but not live site:

2). We have a node in both edit and live sites and also identical (sync). Now I want to unpublish. After unpublish, this node should still sit on edit site but remove it from live site. Let us start from edit. Let us drop this node into the queue but we are not going to delete this node from edit site but how does transfer service know that this is deleted node. For queue, we don't have any specific flags so that transfer service will know that this is the node to be deleted or this is the node to be update or this is the node to be created.

Please let me know if I am wrong. Again thanks in advance.

[qsdmv]

I just read the documentation from wiki. I noticed from 3.4, you can delete nodes in the following way:

1). A new mode of transfer "Sync". So nodes can be deleted if they are absent on the source repository. It seems that it answers the question but don't have example or not sure what it exactly means;

2). Delete a node by transferring node's Archive node ref. I guess that it answers "unpublishing" so that I just delete the node from live without deleting it from source (edit site).
Again, no example showing how to approach it;

Thanks

[bremmington]

Sorry, I'm not sure that I'm understanding. It is possible to implement an "unpublish" function as I described in my post here on 1/May. Is that approach not working for you?

[qsdmv]

Basically your approach is not working for real life. This is what your approach does:

1). Implement unpublish action. The action will do the following logic:
    i). Adding the node into remove publish queue (there is no difference between publish or delete publish queue since it handles the same way);
    ii). Then deleting the node (you have to delete from source);
    iii). Then transfer service will delete the node from target

2). The real life unpublish doesn't like this way (When you unpublish, I am expecting that the node will be deleted from target but kept in source). For example, I want to remove the node from target (or life site because we don't need it) but I still want to keep the same node in source. The question would be simple: How do I use transfer service to keep the source node but delete the same node from target??

Hopefully you understand. Thanks for your quick and patient responses.

[bremmington]

Oh. I've just looked at the code, and now I see what you mean - that looks like an oversight. Let me have a think about ways to resolve it.

[qsdmv]

Thanks.

Also we might need BeforeDeleteNode policy you mentioned early for some situations. For example:

We have published the node to live site. Content contributor accidently deleted this node from source (not going through unpublish action). Then content contributor has no chance to add this node into queue and then never has chance to delete from live.

So this is solution:

1). If this node published, we need implement BeforeDeleteNode policy so that it will automatically drop it into queue whenever user delete this node. then transfer service can sync source with target.

2). If this node is not publish, then we don't need to drop it into the queue when user delete. It is just like normal delete.

Fortunately we are not to allow general users to delete section. Otherwise, we have to drop the section tree into the queue to sync published sections and contents.

Thanks.