Jump to content

Not quite a bug: Updating a workflow should not automatically enable it if disabled


Recommended Posts

Posted (edited)

I'm reluctant to even classify this in the "bug" section, but it doesn't really belong in the "Workflow help" area either, so...

 

I keep a lot of workflows on my system, about half of them I leave disabled: they're just for reference or inspiration. When new versions come out and the Update mechanism is triggered (either via Gallery or double clicking a new version of its .alfredworkflow) Alfred silently re-enables these disabled workflows. Not such a big deal, I just have to try to remember to re-disable (is that a word?) them after.

 

So TL;DR- it would be a bit nicer if Alfred did not change the disabled state of workflows during updates 🙂

Edited by luckman212
Link to comment
  • luckman212 changed the title to Not quite a bug: Updating a workflow should not automatically enable it if disabled

Hi Luke,

 

This is actually by design, specifically to automatically enable the workflow if somebody reinstalls or updates it. Removing the step to re-enable the workflow eliminates any confusion as to why the workflow wouldn't be working.

 

I suggest that you configure the workflow list to only show the enabled workflows (from the ... button next to the search field), that way, you won't accidentally update workflows which you aren't using.

 

Cheers,

Andrew

Link to comment
Posted (edited)

The thing is I do want to update the disabled workflows - because like I said, I use them for reference etc. I just don't want the keyword/hotkey triggers active because they often overlap with my own workflows. Would you consider a setting in the prefs somewhere?

 

[x] Don't re-enable disabled workflows when updating

 

Another possibility would be for Alfred to pop up a dialog during WF updates when the workflow being upgraded is currently disabled:

 

The "foo" workflow is currently disabled. Would you like to enable it? (default button could be Yes)

Edited by luckman212
Link to comment
On 6/9/2024 at 9:50 PM, luckman212 said:

I made a thing to satisfy my OCD for now:

 

https://github.com/luckman212/alfred-workflow-configurator

 

image.png.cd2fa9ac748142ea39f21e973e3c4962.png

 

alfred-workflow-configurator -- Possible to package more as workflow  with .alfredworkflow extension so that it is easier to use?

 

Also is it possible to check if all enabled workflows are working i.e. not really passing argument to run workflow  but to atleast  activate via keyboard i.e. kind of brief checking if compile is working. For now, I do this manually every few months.

Link to comment

@TomBenz Feel free to fork and modify to suit your needs. The purpose (for me) of this was to keep my workflow configuration (and now Alfred Preferences.app settings as of v1.0.1) in a consistent state automatically via scheduled background script. It's not something I want to have to run manually in Alfred—that would defeat the purpose.

 

Your other idea of a "workflow tester" is interesting, but completely out of the scope of this little project. I'm not sure how that would be possible, it would need to iterate over every workflow, looking for scripts (some scripts are external, others are embedded in the workflow objects' XML) and then trying to execute them. This could potentially be dangerous or destructive, depending on the scripts. There are many workflows that may contain scripts which are disabled or no longer have any code paths pointing to them (I have lots of these!)—it could be risky to execute these scripts blindly.

Link to comment
1 hour ago, luckman212 said:

@TomBenz Feel free to fork and modify to suit your needs. The purpose (for me) of this was to keep my workflow configuration (and now Alfred Preferences.app settings as of v1.0.1) in a consistent state automatically via scheduled background script. It's not something I want to have to run manually in Alfred—that would defeat the purpose.

 

Your other idea of a "workflow tester" is interesting, but completely out of the scope of this little project. I'm not sure how that would be possible, it would need to iterate over every workflow, looking for scripts (some scripts are external, others are embedded in the workflow objects' XML) and then trying to execute them. This could potentially be dangerous or destructive, depending on the scripts. There are many workflows that may contain scripts which are disabled or no longer have any code paths pointing to them (I have lots of these!)—it could be risky to execute these scripts blindly.

Thanks for your input. My skill levels are still at basic level but I am learning and will modify the workflow configuration script further.

 

On workflow tester, I don't run fully or all parts of workflow when I do the manual check. It is basic check to figure out workflows where path of Python etc needs to be updated.

Link to comment
4 hours ago, luckman212 said:

@TomBenz I don't know if this is what you're looking for, but I made another thing. Finds scripts with broken interpreters. It's a Zsh script, but could be made into a Workflow I suppose.

 

https://github.com/luckman212/shebangeroo

 

image.png.e8a449b8f79b3b1557fef6653c6c2539.png

thank you. I passed the alfred preference location as path and got below results 

==> run completed on Tue Jun 11 16:25:49 IST 2024
  | elapsed time: 137 seconds
  | 64 bad shebang(s) found! -- will have to understand this further! 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...