Alleyoop: Update Alfred Workflows

[jonathanwiesel]

Great workflow, easy to implement, useful as hell.

Good job =D 

[oderwat]

I just added it to myl "Last changed Files" Workflow and it works like a charm! http://www.alfredforum.com/topic/1715-find-files-recently-changed-similar-to-trickster-functionality/

[samvlu]

Woooow! Amazing!

This should be built into alfred!

 

Great work!

[Andrew]

As posted at the top of this thread - While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.

[pstadler]

Sounds like a plan. Thank you Andrew.

[Guest]

As posted at the top of this thread - While this is a convenient method for updating workflows, I cannot endorse the use of it unless you are fully aware of the security implications of blanket updating all of your workflows. I'm currently working on a built in workflow auto-updater, for a future Alfred 2 release, that performs the standard verification checks that Alfred currently does on manual import, along with migrating your hotkey/keyword settings on upgrading. I'll also be adding 3rd party workflow developer signatures to keep you safe.

 

Excellent. Thank you.

[phyllisstein]

Hey all,

After receiving a gentle nudge from Andrew, I've rejiggered this workflow so that rather than bulk-extracting files you may not want bulk-extracted, it'll download updated .alfredworkflow files to ~/Downloads, where the user will be expected to open them. This ensures that all Alfred's checks, including the stripping of new hotkeys, are performed on workflow updates. The important thing for developers is that the JSON format has changed slightly—almost imperceptibly—to ensure that old versions of Alleyoop won't work anymore. Rather than specifying the key "download_uri", developers should now specify the key "download_url" in their remote JSON files. This will be expected from version 2.0, just posted, on. Sorry if the change seems like a lot, but just figure it'll be less effort than writing a new forum post every time you fix a bug, yes?

[Carlos-Sz]

Hey all,

After receiving a gentle nudge from Andrew, I've rejiggered this workflow so that rather than bulk-extracting files you may not want bulk-extracted, it'll download updated .alfredworkflow files to ~/Downloads, where the user will be expected to open them. This ensures that all Alfred's checks, including the stripping of new hotkeys, are performed on workflow updates. The important thing for developers is that the JSON format has changed slightly—almost imperceptibly—to ensure that old versions of Alleyoop won't work anymore. Rather than specifying the key "download_uri", developers should now specify the key "download_url" in their remote JSON files. This will be expected from version 2.0, just posted, on. Sorry if the change seems like a lot, but just figure it'll be less effort than writing a new forum post every time you fix a bug, yes?

 

One of the weak Alfred features is importing/installing a new workflow. The stripping thing is brutal, specially if you are just updating a workflow. In addition, while setting a hotkey Alfred should not allow any triggering. Sometimes, while reconfiguring for a hotkey, I forget about an already used hotkey and I ended up creating a zip or a note somewhere…

 

I see the need to change the JSON but I’m not sure how good it would be in fact (developers with one version, users with another and vice-versa). Aren’t we trying to kill a bug with a machine gun?

[Andrew]

One of the weak Alfred features is importing/installing a new workflow. The stripping thing is brutal, specially if you are just updating a workflow. In addition, while setting a hotkey Alfred should not allow any triggering. Sometimes, while reconfiguring for a hotkey, I forget about an already used hotkey and I ended up creating a zip or a note somewhere…

 

I see the need to change the JSON but I’m not sure how good it would be in fact (developers with one version, users with another and vice-versa). Aren’t we trying to kill a bug with a machine gun?

 

I've already coded the hotkey / keyword migration for [manually] updating / importing workflows for 2.0.3 for when it's released, which shouldn't be in the too distant future.

[Carlos-Sz]

I've already coded the hotkey / keyword migration for [manually] updating / importing workflows for 2.0.3 for when it's released, which shouldn't be in the too distant future.

 

Great news. I can finally move my Alfred rating from 9.99 to 10.

[phyllisstein]

One of the weak Alfred features is importing/installing a new workflow. The stripping thing is brutal, specially if you are just updating a workflow. In addition, while setting a hotkey Alfred should not allow any triggering. Sometimes, while reconfiguring for a hotkey, I forget about an already used hotkey and I ended up creating a zip or a note somewhere…

 

I see the need to change the JSON but I’m not sure how good it would be in fact (developers with one version, users with another and vice-versa). Aren’t we trying to kill a bug with a machine gun?

The change just has to be made on the developers' side; it's transparent to users, except that they'll notice that workflows stop updating if they're still using an unsafe version of this workflow or the developer hasn't switched over yet. Because I'm very sympathetic to Andrew's concerns, I want to make sure that people are more or less forced to make the switch. A bit authoritarian, I admit, but better safe than sorry.

[DJay]

I'm a bit confused. 

Alleyoop "oop" showed me two workflows who need to be updated.

Convert Word document to PDF V1.0 to V1.1

Built-in Sharing V1.5 to V1.6

 

But after updating Alleyoop downloaded the old versions to the download folder.

 

 

What am I doing wrong? I think I use the latest Version of Alleyoop as well.

 

Thanks for the help.

Edited April 7, 2013 by DJay

[phyllisstein]

I'm a bit confused. 

Alleyoop "oop" showed me two workflows who need to be updated.

Convert Word document to PDF V1.0 to V1.1

Built-in Sharing V1.5 to V1.6

 

But after updating Alleyoop downloaded the old versions to the download folder.

 

 

What am I doing wrong? I think I use the latest Version of Alleyoop as well.

 

Thanks for the help.

Though I hate to pass the buck, I'm afraid that's something you'll have to take up with the individual workflows' developers. If Alleyoop is downloading something to ~/Downloads, then I suspect it's doing its job; the problem you're experiencing indicates that the workflow developers left outdated files or links on their servers.

[_mk_]

Would it be possible do an

 

open <workflow>

 

at the command line after the workflow was downloaded? That way one would not have to go to the Downloads folder and search for the download to double click it manually.

 

I also recognized, that you rename the workflow to its Alfred name. Mine is called OF-TaskActions.alfredworkflow on the server but ended up as "OF / TaskActions.alfredworkflow in my Downloads folder. Is there a special reason to do the renaming? I thought Allayoop would just do a curl to download the stuff...

[vdesabou]

Though I hate to pass the buck, I'm afraid that's something you'll have to take up with the individual workflows' developers. If Alleyoop is downloading something to ~/Downloads, then I suspect it's doing its job; the problem you're experiencing indicates that the workflow developers left outdated files or links on their servers.

 

I am the developer of the workflow.

 

To reproduce the problem, I've updated my update.json with version 1.5 (instead of current one which is 1.6), so that alleyoop thinks there is an update:

 

{
    "version": 1.5,
    "remote_json": "https://dl.dropbox.com/u/2407971/alfredupdate/builtin-share.json"
}

 

 

The builtin-share.json files contains:

 

{
    "version": 1.6,
    "download_url": "http://d.pr/f/cj9L",
    "description": "Start Droplr if needed before trying to upload."
}

 

When I download manually the file at http://d.pr/f/cj9L, I get:

 

cksum Built-in\ Sharing\ 1.6.alfredworkflow
2743814521 253360 Built-in Sharing 1.6.alfredworkflow

 

But when I update it via Alleyoop, I get:

 

cksum Built-in\ Sharing\ 1.6.alfredworkflow
3801960702 10339 Built-in Sharing 1.6.alfredworkflow

 

Which is not a valid alfredworkflow file (10k instead of 257k)

 

(I tried renaming without spaces, but I get same issue)

 

Any idea what could be wrong here?

[CarlosNZ]

I am the developer of the workflow.

 

...

 

Any idea what could be wrong here?

 

Just from a quick glance, the link http://d.pr/f/cj9L points to a Droplr page rather than the direct file download. The direct download link is what you need to point to in your json file. (Not sure if you can even provide a direct download link from Droplr -- you can with CloudApp though.)

[phyllisstein]

Just from a quick glance, the link http://d.pr/f/cj9L points to a Droplr page rather than the direct file download. The direct download link is what you need to point to in your json file. (Not sure if you can even provide a direct download link from Droplr -- you can with CloudApp though.)

Thanks, Carlos. I believe that is indeed the problem: Droplr doesn't automatically redirect you to the file you're trying to download, so the workflow is downloading the raw webpage data and trying to call it an alfredworkflow file. You should try to link directly to "YourWorkflow.alfredworkflow" whenever possible, or to a URL that reliably redirects to "YourWorkflow.alfredworkflow" (like a bit.ly link).

 

The workflows are stored by name in ~/Downloads because that datum can be extracted from their Info.plist files, whereas the original filenames can't. And I can't reliably grab the workflow filename from the web address, for fear of breaking it for people who use redirect services. As for auto-opening the file after it's downloaded, I'd prefer to leave that to the user, who should be able to eyeball the file for potential maliciousness at some point in the process.

[vdesabou]

Just from a quick glance, the link http://d.pr/f/cj9L points to a Droplr page rather than the direct file download. The direct download link is what you need to point to in your json file. (Not sure if you can even provide a direct download link from Droplr -- you can with CloudApp though.)

 

Oh yeah, that was it!! Thanks!

[_mk_]

The workflows are stored by name in ~/Downloads because that datum can be extracted from their Info.plist files, whereas the original filenames can't. And I can't reliably grab the workflow filename from the web address, for fear of breaking it for people who use redirect services. As for auto-opening the file after it's downloaded, I'd prefer to leave that to the user, who should be able to eyeball the file for potential maliciousness at some point in the process.

 

OK. For security reasons I understand your decision. Would it then be possible to include the version in the file name or maybe preselect the file in Finder to make it easier to find the download? I tend to fill my Download folder and even sorting the files by modify date does not ensure that the sop most file is the downloaded workflow.

[R4z3r]

Great job! I've updated my TVRage workflow to take advantage of this. I look forward to using a developer signature or dev id to make it a bit safer

[albertkinng]

found 1 update! woohoo! I love this workflow!

[parekh]

Thanks for creating this workflow, but unfortunately it doesn't work for me. It shows that I am able to download and install one update (Evernote 4.5 to 4.6), but when I select the option it doesn't actually do anything. I get an Alfred notification saying "Alleyoop: all updates complete" but nothing has actually happened. Thank you for reading this.

[phyllisstein]

Thanks for creating this workflow, but unfortunately it doesn't work for me. It shows that I am able to download and install one update (Evernote 4.5 to 4.6), but when I select the option it doesn't actually do anything. I get an Alfred notification saying "Alleyoop: all updates complete" but nothing has actually happened. Thank you for reading this.

 

I'm sorry it's giving you trouble! Did you just get the one notification, or did you also get one that said "Downloaded Evernote"? And since I have to check the obvious thing, did you check your ~/Downloads folder for a new .alfredworkflow file?

[phyllisstein]

I think that I've spotted the issue that was causing @parekh problems. I've updated the workflow, but it may have to be manually downloaded from this link, as I suspect that its self-update mechanism was affected by the bug.

[judgejohn82]

Hey,

 

One issue I have with this is that if I input the oop? command to check which of my workflows are compatible, it stalls on "Checking installed workflows..." and never displays the list.

 

Any ideas?