Multiple parents for document and deletion trouble- addchild

[annakan]

Hello all.

We need to be able to have a document inside two folders (one as work-flow basis, the other as filing/"storage").

Looking around the forum (http://forums1.man.alfresco.com/en/viewtopic.php?f=6&t=16170) and doc we built an action that take the target folder (where the "duplicate" should land) as a parameter.

We use the nodeapi.addChild API to create a new association of type ASSOC_CONTAINS between the target folder and the document, with the document name, like this

ChildAssociationRef ref =  this.nodeService.addChild(destinationParent, actionedUponNodeRef, ContentModel.ASSOC_CONTAINS, destinationAssocQName); ‍

In the object browser the two relationship look the same, except for the "primary" attribute.

But when we delete the document from the "source" folder, although alfresco properly warns us about multiple containments, the document disappears from the source folder but notfrom the "target" folder.
Well, not exactly, in fact a "proxy" seems to be left over in the target folder (and is persistent there) but attempting to inspect it or delete it brings an errors saying that the underlying node as been destroyed.

We suppose some "proxy" object is properly created in each folder with the addchild call but not deleted when the document is deleted from one of the folder.

If we do it the other way, deleting the document from the "target" folder, no warning is issued (is that because the relationship is not 'primary' ?) and we can then delete the document from the "source" folder without the "duplicate location" warning.

• Are we supposed to do something to the relationship we create to get the proper behavior ?



• Can we and shall we  set primary=true on both relationship ? and if yes, how ?



• Should we do something upon deletion ? (would be weird since alfresco seems to know there is multiple parenthood  and be ready to handle that).



• Is there some example of that ? (For instance in the record management "extension" of alfresco ?)



• Did somebody successfully implement such a behavior or action that gives multiple containment to a document ?

We think it is a very important and smart feature of alfresco to be able to host a document into multiple folder with various deletion strategy, allowing different views on the content and states of the document depending on the usage or population. For instance a document can be archived/stored by an assistant while pending a contractual review process, giving at the same time a unified view of the documents in the "store" and an object of work-flow into multiple spaces.

We eagerly awaits any pointers or code sample or technical explanation that would un-stuck us.


Thanks a lot for your time.

EDIT : using the node browser we saw that at first the two documents nodes are identical save for the "primary" attribute but when we delete from the source folder the "document proxy" in the target folder becomes a link toward an "archive:" storagespace.
It looks like the deletion command do some extra hard-wired tricks in that case that are not generic enough, maybe leftovers from the record management functionality ?

And by the way, doing the same thing with javascript gives the same behavior.

var duplicateFolder = space.childByNamePath("Duplicate"); 
duplicateFolder.addNode(document); ‍‍

What can we do to have the proper basic behavior of deletion ?

[annakan]

Nobody has a clue ?

We are evaluating Alfresco on a small scale project and this is vital to avoid the messy workflows that would prove to be too constraining anyway.

Plus it is a great functionality for people workflows or not, it allows the same document to be filled under two logics, corresponding to different usages ('sorting plan' on one side, working reviews on the other side) that often conflict in a document lifecycle.

Last it allows very graphical / CIFS like process that are easier for occasional users who can even be un aware there is a DM in place.

We have a short time frame to complete this proof of concept, and it would be a big plus for Alfresco to be able to do something useful in this time frame, and it is quite frustrating to have the whole action stuff nearly working, but not  quite …
Far away, so close

So any pointers appreciated

[lotharmärkle]

I am not sure what you really meant by "doing the right behaviour" and what you want to achieve. Maybe you could just be more clear about this? Do you want the archive:// Noderef to be removed or do you want to remove a document which you linked in two spaces individually or …

There can be only exactly one primary association to a parent node.
This primary assoc controls the "contains" behaviour - that is, the life cycle of a node is controlled by its primary parent node. In other words, deleting a node will delete all its "primary" children as well. In contrast, all children of the deleted node, which have secondary assocs to it will not be deleted.

The mysterious archive://… node reference you see belongs to a node of the trashbin - it was deleted and the secondary assoc was changed to point now to the document located in the trashbin. If you empty the trashbin this will be removed too. So its not some kind of proxy or leftovers, its just a node reference.

HTH
   lothar

[annakan]

Thanks for your anwer I missed it because somehow I must have forgotten to activate notifications.

Thanks for your explanation, I less cleanly arrived to the same conclusion but was disappointed by some design decision :

- you must have one primary parent-child assoc, meaning you can't have "delete on last un-parenting" behavior.
- Or delete on "any" un-parenting behavior
- although afresco model supports multiple parents and this is GOOD and GREAT and much better in my book than the "proxy/stub" model, Alfresco forget that right away, implementing copy and move without passing the "source parent" information. The consequence is that the source is always fetched from the node itself, assuming it is its primary parent. That is wrong of course.

The consequence is that, when you assign multiple parents to a node/document, you can't act on any of the "non primary childs", all acts upon any of those is carried upon the arbitrarily elected "primary child" (the first parent at creation time in fact).

The moveTo and copy to signature are like this fn(node, destination), instead of fn(node, source, destination).

I was able to make work the multiple parenthood but I need to rewrite the copy and move action to be able to progress, something even more ambitious

On a side note they had to "do it right" for the CMIS implementation where a source and a destination are expected.

[mrogers]

I think you may find that the copy scenario has been fixed …   It looks like a familiar issue.

I like your idea of delete on last reference, but you are right that its not there at the moment.

[annakan]

Great news

Fixed in the SVN ?

and the move action ? (greedy me)

To know if I still have to make my own (makeshift) custom move action.

As for the deletion policy, I happen to think that the "delete on last reference" is the most "sound" and generic but I would even be nice if we could choose the policy on a document type by document type basis.

More generally It would be nice if the move behaviour was preceded by onBeforeMove allowing us to mingle with the source and destination folder, thus implementing any policy.

As I said, greedy

[rss]

We found the similar problem with Alfresco Share (r26807). (deleting and moving actions).

E.g.:
var folderNodeRef = "workspace://SpacesStore/e7bfa076-ab8a-4211-b821-e367ee36d33e"; //existing space "test"
var fileNodeRef = "workspace://SpacesStore/7831203d-805e-42d9-9a36-e4d1abbed1f0";  //existing document "file1"
var folderNode = search.findNode(folderNodeRef);
var fileNode = search.findNode(fileNodeRef);
folderNode.addNode(fileNode);
—-
Enter into space "test" and make action "delete". The document is really deleted and vanished from both primary and "test" spaces. But any trying to add a document with the same name "file1" into the primary space generates the following exception: "org.mozilla.javascript.WrappedException: Wrapped org.alfresco.service.cmr.repository.DuplicateChildNodeNameException: Duplicate child name not allowed: Файл1 (workspace://SpacesStore/Company Home/Data Dictionary/Web Scripts Extensions/………ourscript.post.json.hs#948"

We checked that the document is really deleted ( fileNode = search.findNode(fileNodeRef) returns null ), but folderNode.getChildren() for the primary space return Node-object with a name of the deleted document.

PS: the reason for using multiple parents for document for us is absence of virtual spaces. We need to process dynamic hierarchical lists of documents (working with clusters of documents) allowing all actions that possible in AlfrescoShare Document Library.

Moreover it is very strange that Alfresco Share contain different realizations for browsing documents in the library and viewing search results because it makes impossible to use actions for documents in search result that accessible for documents in the library.

[heiko_robert]

moving a secondary is fixed now but I created a ticket in JIRA since deleting a secondary will still delete the primary node (tested in 4.2.c) ALF-18792.
The suggestion from Annakan would fix the issue