Request vs. Install in Self Service

[mortopc4]

My apologies if this has been discussed here, but I'm a bit stumped.

I am making a few titles available through Self Service. Currently they are set to "install" when you access them through Self Service.

What I would like to do is to change the button from "install" to "request" -(which would then direct the user to our Help Desk ticketing program, Remedy, to submit a ticket requesting approval to install the title in question) OR change the 'install" to "download" (which will kick off the downloading of the application to the users client).

Again, thanks for pointers/suggestions! Cheers!

[#2]

You can create Self Service plug-ins that open URLs, which obviously can be http/https or other protocol handlers, such as mailto:

Since there's still no straightforward way to add a computer to a static group via policy or script, you could just create a dummy package and then smart group for presence of its receipt to determine which users have 'requested' that title, or even just script something which touches .somefile from the policy in Self Serve and then scope the group to that..

[Josh_Smith]

"Install" Button: You can make this button say whatever you want*, it just runs whatever you have configured the policy to do. You can change the button label for each policy in the Self Service tab. (*I assume there is a character limit)

"Download" button: You can make the button display "Download" and then configure the policy to cache a package or install a package that just copies your files down to the computer somewhere.

Request/Ticket creation: I don't use this, but I think you would write a script leveraging the ticketing systems API. You could prompt for user input or pull values in automagically. Basically your policy would comprise of a custom script.

Another option would be to use the Self Service Plugins(or a policy) that just opens the URL to a pre-existing request form in a browser.

[BrysonTyrrell]

@mortopc4

I did something like this for a while. I wrote a script that took in parameters from a policy and generated a Zendesk ticket on the behalf of the user who ran it. It allowed us to display all of our software (VPP and otherwise) that we distributed and users could make requests for procurement.

[Look]

If you don't want to use a plugin or talk directly to the system you could have the policy run a script to call a URL to the ticketing system (if it's web based of course) in the default browser and depending on the system potentially have it prepopulated with a couple of arguments (or whatever the proper name is for the variables on the end of a URL...).

Something similar to this in a script

osascript<<END
tell application "Finder"
open location "http://ticketing_system.com/new_ticket_page.html?info_to_pass"
end tell
END