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

[luckman212]

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 June 6 by luckman212

[Andrew]

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

[luckman212]

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 June 7 by luckman212

[luckman212]

I made a thing to satisfy my OCD for now:

 

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

 

 

Edited June 9 by luckman212

[TomBenz]

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

 

 

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.

[luckman212]

@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.

[TomBenz]

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.

[luckman212]

@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

 

[TomBenz]

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

 

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! 

[luckman212]

The pathnames to the scripts that it thinks are broken should be listed above that "run completed" line... it also should have printed the bad executable names along the way to the console during the run. Did it not?

[luckman212]

@TomBenz I just released an update to this, give v1.1.0 a try please.

 

https://github.com/luckman212/shebangeroo/releases/tag/1.1.0

 

[TomBenz]

11 hours ago, luckman212 said:

The pathnames to the scripts that it thinks are broken should be listed above that "run completed" line... it also should have printed the bad executable names along the way to the console during the run. Did it not?

Yes, it is working well. Thank you.