When publishing documents, my users have requested to archive all documents as a specific type when they drag and drop an entire folder from the 'Available ReadyDocs' panel to the 'Selected ReadyDocs' panel. The document type will be based upon the folder then have moved and they only want to perform this action when an entire folder is selected.
Is this possible? I am not seeing any metadata in the IPrintJobItem properties that could solve this request other than the 'DocReportGroup'. I am thinking of having the users assign all documents within each folder to a group that is specific to that folder, then I will map the group to their specified document type. I think that should work but wanted to check if there is a better method. Also this doesn't allow me to know if an entire folder was dropped which is one of their primary requirements.
Thanks,
Bob
Drag & Drop Folder Name in Documents Selection
-
Mark McKenna
Re: Drag & Drop Folder Name in Documents Selection
The fact that a folder drag action caused documents to be added to the selected list is "lost" immediately. Instead, we flatten the document nodes under that folder node and add them individually. Once rendering begins and a print job subsequently passes through the pipeline, therefore, it is effectively as though the documents were added one by one.
Your Group approach would technically work, although it does introduce coupling between the document definition and its location in the tree. This becomes problematic if the document is located in more than one folder, or in different folders for different users with different trees. Further, and perhaps more importantly, our default document collation handler uses the Group value as part of its sorting algorithm, so doing this could cause document sorting to go awry.
If you were to generate sets of document IDs that live under each folder node for which this action may legitimately occur, you could scan all the original print job items and see if you have a complete match, which you could then assume to have been the result of a folder drag. Of course, this also introduces a maintenance issue as trees change over time. On the plus side, it requires no change to the document metadata.
Your Group approach would technically work, although it does introduce coupling between the document definition and its location in the tree. This becomes problematic if the document is located in more than one folder, or in different folders for different users with different trees. Further, and perhaps more importantly, our default document collation handler uses the Group value as part of its sorting algorithm, so doing this could cause document sorting to go awry.
If you were to generate sets of document IDs that live under each folder node for which this action may legitimately occur, you could scan all the original print job items and see if you have a complete match, which you could then assume to have been the result of a folder drag. Of course, this also introduces a maintenance issue as trees change over time. On the plus side, it requires no change to the document metadata.