Two possible solutions for you:
You can try renaming AFTER the checkin... it is only a pdf so it should not create any issues but always test :-)
There is a little trick involved with Dispatch scripts and renaming... Dispatch only knows the name, path, etc of the original file. If you rename the file you will have to enter the entire path to be able to check in the file. You can make this easier by creating variables in Disptach and extracting this information from the original file to combine it into a variable for the path of the renamed file (it will help a LOT as the interface for scripting is horrible to say the least).
How is the PDF created/added to the vault? (Is it a SW file or other files type?). How is the revision set?
Why do you want it renamed on checkin? Since you are appending a revision, would it make more sense to trigger on a specifc transition?
If you have a dispatch automatically triggering on checkin, are you eaking sure that it only works on specific files?
I'm not a fan of Dispatch actions being automatically triggered unless vigorously tested for all situations. (You tend to forget you have them :-))
I appreciate your help!
The PDFs will be produced from various programs in addition to SolidWorks, especially Altium Designer.
The revision letter comes from the data card. That variable is mandatory, but you will quickly see that once it is entered, there is no way to require the submitter to update it. That will be a management issue.
Having the revision number in the file name is how we keep the PDF with the original CAD files.
Currently, we require the submitter to manually name the file, but I was hoping Dispatch could automate the task.
Ideally, the script would run when the file is released.
This may be too much to ask of Dispatch. At least I learned how to create a script that runs manually.
Thanks again. . .
Hi James -
So, is the revision letter entered on the data card manually or via the workflow?
If you 'could' have it renamed automatically upon release, would it be for all PDF's that passed to that state or would they need to be filtered somehow?
As I get deeper into this effort, I see multiple problems . . . er, issues.
However, here's what I was getting at:
When multiple revisions of the same file exist in PDF form, we prevent previous revisions from being over-written by adding the Rev letter to the file name. This also makes it possible to quickly locate the desired file.
Aside from SW files, there is no way to automate annotating the Revision letter on the PDF data card, so that must be entered manually. I was attempting to use that data card variable to add the Revision letter to the file name.
As I test the script manually, I discover unforeseen gotchas and frankly I don't think my idea is a good one.
It has been educational, however!
Hi James -
There are a lot of things to consider when automating anything
Okay - so I did figure out a way to do it 'automatically'.
First - when changing state to Approved (see my workflow image) the revision letter is typically being written to the data card via Set Variable on the preceding transition. This means that a new version is created so therefore, there is no revision value to capture and add to the filename.
So, what you could do is move the Set Variable to the transition preceding the previous state (Waiting for Approval). This action will write the value of the next revision to the data card, but, won't actually increment the revision. This also requires that you add the revision scheme to the Waiting for Approval state, but, remember to remove all incrementing. You would also need to reset the revision if you move the file back via the Editing Required transition.
Once you have done this you can then proceed with writing the rename action to fire on the change state.
This is when you typically discover problem 2 which is: if I once again 'rev' the file - the dispatch action needs to omit the previous revision from the filename.
The easist way to do this is to store the original filename somewhere on the datacard and use this as the basis of constructing the new filename.
Whew...see my attached video to take you through the entire scenario
Although my plan is probably full of bomblets and impractical, your solution is chock full of great tips.
I'm sure many of us neophytes will get a lot out of poring over what you have posted, as I have from many of your posts.