strange action behaviour on script filter

[juliosecco]

Hi,

I found a strange behaviour that maybe makes sense to note.

I have experienced it on my workflow, but I have created a little 'test workflow' to isolate it.

 

the workflow has only one script filter and a post notification to see if the action on the filter goes on.

the script filter has this php code:

 

<?php

$items = [];

$item = array(

'title' => "No results with this filter",

'subtitle' => "This is an item that should not be actioned",

);

array_push( $items, $item );

$stringa = '{"items": '.json_encode($items).'}';

die($stringa);

?>

 

that simply outputs an item without 'arg' and without a 'valid' parameter, that in my intentions should not be actioned.

 

the strange thing is that if the script filter has the 'Argument required' option, effectively the item will not be actioned, while if the script filter has the 'Argument optional' set the item will be actioned and I will see the post notification hitting enter (idem with 'No argument')

 

I know now, thanks to deanishe, that setting 'valid' to false will avoid the item actioning in both cases, while I was convinced that not setting an arg was enough, but maybe is a difference that worths a check?

 

I have Alfred 3.1 pre-release, don't know sincerely if the problem was always there before

OSX El Capitan 10.11.6

Edited August 3, 2016 by juliosecco

[Andrew]

the strange thing is that if the script filter has the 'Argument required' option, effectively the item will not be actioned, while if the script filter has the 'Argument optional' set the item will be actioned and I will see the post notification hitting enter (idem with 'No argument')

 

I know now, thanks to deanishe, that setting 'valid' to false will avoid the item actioning in both cases, while I was convinced that not setting an arg was enough, but maybe is a difference that worths a check?

 

Alfred is actually working as expected and dean's response to this (using the "valid" parameter) is correct if your intention is to prevent a result from being actions. Essentially, if you leave the arg field empty, Alfred treats this as a valid result but empty arg. This is actually warned about in the documentation:

 

"While the arg attribute is optional, it's highly recommended that you populate this as it's the string which is passed to your connected output actions. If excluded, you won't know which result item the user has selected." (https://www.alfredapp.com/help/workflows/inputs/script-filter/json/)

 

The "Argument Optional" and "Argument Required" more relates to what the user is typing into Alfred. To clarify this, if you select "Argument Optional", the first time your script will be run is with an empty argument. If you select "Argument Required", the first time your script will be run is when you have typed some argument. This means that "Argument Optional" allows actioning of results when no argument is typed.

 

It's also worth noting that Alfred actually has some (failsafe) logic which sees a result as incomplete if the actual JSON/XML result's arg parameter is empty and you have set "Argument Required".

 

Cheers,

Andrew

[deanishe]

So Argument Required is passed through to the results, too? When you say arg in this context, do you mean before or after Alfred has parsed it for JSON? Like, if I set some workflow variables, but no arg, will the result be actionable?
 
My bad regarding explaining Alfred's behaviour. I guess that was actually Alfred-Workflow's behaviour, as it sets valid=false if arg is unset.

Edited August 5, 2016 by deanishe

[Andrew]

So Argument Required is passed through to the results, too? When you say arg in this context, do you mean before or after Alfred has parsed it for JSON? Like, if I set some workflow variables, but no arg, will the result be actionable?

 

My bad regarding explaining Alfred's behaviour. I guess that was actually Alfred-Workflow's behaviour, as it sets valid=false if arg is unset.

 

 

Essentially, the "Argument Required" is used by Alfred to decide how to process the current workflow (or internal feature). The "arg" is slightly different to this, in most cases (in particular for internal features), the arg likely matches the typed argument, for workflows and script filters, the 'arg' can be anything. This is why the two things should be really treated separately, and valid = false is the best way to go to get the desired behaviour.

 

The failsafe I was talking about is just a little bit of code to prevent a workflow or internal feature with "argument required" set actioning / passing an empty argument out of it if the 'arg' is empty.

 

Cheers,

Andrew