please attach the wft. wfm you are using to do the submit...
We're using TS 6.5.0 Service Pack 2 - no workflows.We've had several instances of where a user has marked a file as "private" in the properties link in TeamSite, and the file has been manually deleted off the production server. Our intention is that the file no longer reside on the production server and remain in TeamSite, but somehow the files are being re-submitted and deployed, even though marked private. I'm suspecting that a user is hitting the "Submit" button while working in a specific folder, which usually submits everything that has been updated in the folder. Apparently, though, that's also submitting the private files as if they had not been marked private.Anyone had experience with this sort of situation, and did you find a work-around (beyond "user education")?
First, if you are using 6.5 you MUST be using a workflow if you are submitting from the GUI. (OK, so I have seen 1 place that had a custom menu item that ran iwsubmit, but i doubt this is the case).So, since you are very likely using a WF, that means you do have a WFT. Now if you used an out of the box WF (like configurable default submit) it likely attaches everything in the folder to the WF, which includes private files.There is a thread in the perl forum on this topic. Have written an update to a WF that will expand a folder to include all modified files under said folder, exclude any files locked by someone else and exclude templating files (zz_tst). That can be expanded to filter out private files as well, however, since the CLT to determine if a file is private or not, works on a single file, you would to run this on very file you submit (which could take a very long time).Anyway read the thread in perl (it is very recent), I am writing a KB with code samples so you can try to incorporate my changes if you so desire.HTHAndy
By default, I believe that unless a private file is selected (either physically, or through some recursion code in the workflow), TeamSite should not be attaching such files to the workflow - e.g.: if you're at the root of your workarea and click Submit with nothing selected, only the modified / non-private files and directories should be attached to the job. I haven't verified this recently - but that was the way it used to work, and the way it is supposed to work.It is possible that new directories with private files inside them might cause problems with the internal algorithm - but I haven't verified that either.A number of custom implementations (such as Nippers) will tend to identify directories that are attached to a job and replace the directory entry with a complete list of all files within that directory. As such, this custom code needs to be bullet-proofed to skip over private files.
A couple points. First, the workflows are "solutions" and not necessarily production code. The discussion I had with Smitty a couple years ago was on this exact topic, he would submit a folder and the OOTB workflow took all files under the folder, whether private or not.