Return file to folder of origin

[TheCaptain]

This is going to sound a bit garbled, but perhaps my intent will shine through!

I've got an Applescript that runs as a Service item which can be accessed when right clicking on any given file that a User may have on their computer.

In essence, this brings up a List Selection that the User chooses and the file is then sent off to Switch for processing.

An example would be; Right Click a .PDF file on a storage server / Select "For Preflight" / Which copies the file to an Preflight Inbox on Switch / Switch creates a report etc.

BUT, I don't know / can't think of / haven't worked out, how to have Switch return the (in this case) report file to the location the .PDF file originated in.

Applescript took care of getting the file to the Switch Inbox, but I cannot fathom how to do the reverse. I can only figure how to set Switch to drop the new file into a hot folder, or the hot folder the Service duplicated the .PDF to, to trigger Switch initially.

Perhaps I should tag the original file somehow, but if it isn't a .PDF I'm not sure how to go about that.

Any thoughts?!

[TheCaptain]

This is, by the way, to negate the use of the Scripting Module that we cannot currently justify the cost of.

[loicaigon]

Perhaps I should tag the original file somehow, but if it isn't a .PDF I'm not sure how to go about that.

It's how I would likely go but as you say it implies that the file can receive metadata.

Worst scenario, some files cannot be tagged. Your alternatives are numerous but I think the most solid at this point would be to create a xml ticket in the applescript side that is named accordingly. So later this xml can be loaded as a job metadata and you can think of a command line mv operation.

It's all I can think of to avoid the scripting module but it implies the metadata module.

Loic
http://www.oazlto.com

[TheCaptain]

Ah, yes. That was the route I thought I'd have to go down.

The frustrations of being Admin on the tech side only!

[gabrielp]

This is, by the way, to negate the use of the Scripting Module that we cannot currently justify the cost of.

The frustrations of being Admin on the tech side only!

The scripting module is so useful, it seems strange to me that you cannot justify the cost. It not only allows you to make your own scripts, solving problems like this with ease, but it allows you to run other's scripts as well. Not just that, but any CLI app you can easily run within Switch, which is actually really tough to do with the "Execute command" configurator. Some things the scripting module provides, like easy access to writing private data, seem like it would be a huge hindrance to do without. Between having your hands tied with otherwise simple scripting solutions and high price tag of "appstore" scripts, the scripting module is looking like more of a no-brainer.

Back to your problem: the Switch Client essentially does this. It can be expensive but probably worth looking in to.

Personally, if I was preflighting this way, I would not key off of the location it was submitted from, but would reference a job number or some key piece of information. Then, I would have Switch lookup where that file should be and drop the preflight there. In our shop, we have a standardized job directory: "Work in Progress/Live Jobs/11111_Customer A" where 11111 is the job number and Customer A is the customer name. I can get the customer name from the job number, so from the job number I can build it's working directory. So, I would have the user enter the job number or peel it from the file name, then return it into the customer folder or "Work in Progress/Live Jobs/11111_Customer A/Preflight Reports" while probably sending them an email. Again, you could get the email from the information related to the job instead of having the person submitting it enter it.

[TheCaptain]

Ha, yeah, tell me about it!

Inheriting the system as is means we do actually have the Switch Client, however the Users are too (shall we say) 'engaged in their work' to take the time to put files through the SC. A simple Right Click has proven an effective way of gaining user participation.

Your solution is similar to what I have implemented in general terms. But as I am asked to perform more elaborate tasks with files from their locations on the Network, it's proving difficult to return files to where they started.

A better example of what I am trying to perfom would be that a user Right Clicks on an .INDD to send it off to Switch for a High Res / Low Res / and Preflight Report creation, with the files being returned to the relevant folders within the job folder the .PDF initially started in.

I have this working one way with the original .INDD being duplicated to a Switch Inbox, but... hmmm... I could tag the file with a unique ID before it uploads it. Perhaps returns it to a single Folder location, but based on the filename... not sure.