I'm trying to create a local file from a OneStep - Run Report action. To make this usable for all users I'd like to specify a dynamic file path, such as: %UserProfile%\documents\<filename>
When I do this, there is an error specifying that the path is wrong, where I can see that it automatically adds my user desktop path in front of the path I've specified.
Anyone know a good way to do this?
I've had success using the CurrentLoginID system function. I add the modifiers: Lower-case(), and Text After () to remove the domain.
CurrentLoginID = DOMAIN\stevec
result with modifiers = C:\Users\stevec\Downloads\File.extension
Thanks Steve, this was my solution too. However, it seems that users logging in from different environments (Laptop, Citrix, VDI) have differently named user profiles and loginIDs. I will have to control these variations with expressions.
ah, good point. I haven't looked into those scenarios (Citrix, VDI, etc..) yet, but yes, expression(s) and modifier(s) could take care of those variations for you. You might want to create these as Stored Expressions within the None association in the event you need them across multiple BOs.
If your goal is to simply find a location on the local machine that all users should have access to - and where they won't need to actually browse to from the file explorer - then I'd actually recommend using a cherwell 'filename' token (Accessible in your context menu when setting a value in one of those token-accepting fields), as you can configure them to generate a file path with a random name in the Temp directory.
From here you can reference that file's location using a token within Cherwell as if it's a variable, and can even set the one-step to clean up the temp file when the one-step has finished executing. This is a very clean way of operating with files on the local machine.
Another option I prefer is to utilize Powershell.
You can utilize powershell to either collect the user profile path for the current user, or, what I would recommend, to display a SaveDialog to a user which is a windows explorer dialog that prompts them to navigate to the directory and name the file they'd like to save the file as. I'll cover both options here.
Collecting the user profile path of the current user using PowerShell:
Utilize a 'Write to File' command to save a powershell script to the local disk. I'd recommend saving it to a 'filename' location that includes a full file path, as this will create this powershell script in the temp directory. Make sure it saves this as plain-text and not rtf format, and that it's configured to execute before the next sub-step.
The content of this write to file command will be the following command:
$Env:userprofile | out-file "[Token for results file path here]"
Where I've noted for a token for a results file path, insert another 'Filename' token that will be a file in your temp directory. This will be used for reading in the output of this script, and bringing that user profile path back into Cherwell.
Next, you need a 'Run a Program' action.
Configure this action to execute 'powershell.exe' (without quotes) and use the following commandline arguments:
-ExecutionPolicy Bypass -File "[Token for your powershell script]"
Where the token is the filename token you used for saving your powershell script to the disk (In my example 'Powershell File' token in the picture above).
The 'ExecutionPolicy Bypass' section is important because it ensures this will run on machines where powershell is disabled by default.
Important: Make sure to check the box on the Run A Program dialog to wait for the program to end before continuing.
Next, you can read your results back into the system using an 'Update a variable or stored value' action. Use a 'Read content from file' token to read data in from your 'filename' for the powershell results. This will collect the out-putted user profile directory from the temp file cherwell created for this. Make sure you define the format for the read-content-from-file dialog to be plain-text as well, and the boxes for 'read if file name changes' and 'read if content changes' are checked.
You now have a variable with your user's profile directory in it. Append \Desktop to it and you're set.
Option 2: Using a Windows Save Dialog:
This method will be very much the same, only varying from the steps above in the script being used in the 'Write to a file' action. Replace the powershell script I mentioned above (The part with the $Env line in it) with the following lines:
$FileSave = New-Object -Typename System.Windows.Forms.SaveFileDialog$FileSave.ShowDialog()$FileSave.FileName | out-file "[Token for result file]"
Then, as you would have done in the previous steps, configure a variable action to read the content from this powershell script after you've executed it.
Now, you've configured a Cherwell one-step that prompts a user for a directory and file path using Windows explorer to select a file location :)
Feel free to post back if you decide to try these fun / useful experiments (They may come in handy later / for other projects) and run into any issues.
Known issue i've run into when doing this is that occasionally when editing, I've seen the file name tokens break a single time. If this happens remove them wherever they appear (including on the inside of your 'Read content from file' token) and replace them with new ones and it should work fine.
I'll definitely be experimenting with this, thanks for sharing!
Thank you so much Doug, Thanks for providing such a detailed description.
Steve, this is what I did in a single domain environment to write a PDF to the Desktop, just use the modifer to remove domain, with currentLoginID() and build C:\Users\CurrentLoginID()\Desktop around it. You'd be able to run multiple modifiers such as:
1. Remove "Citrix\"
2. Remove "Acme\"
3. Remove "ThirdDomain\"
Or replace \ with a space and take next word, or experiment with the different modifiers. Case expression would also work nicely where you put a blank stored value (since you can't just leave it empty or put a space)
Beyond20 Doug's answer looks good too. I have had an issue where temp directories are not allowed to execute in some environments after a virus outbreak or some security event, or just super locked down domains. Something to remember if you are having trouble, ask security folks for a whitelist or exception.