Avoid result actioning

[juliosecco]

I found a bug on my workflow,

but is quite difficult to explain, I'll try:

 

I have an initial script filter where I type to filter items (CSS properties)

I can go on and filter until only one property is shown, hit space and begin filtering for its values on this first filter, or I can 'action' on the filtered list to pass to a following script filter to select the values for the selected CSS property.

 

Both on the first and second script filter, when the filtering does not produce results, I output a warning row. This row has no "arg" parameter, which is what I assumed disables the action on it.

 

The strange thing is that in the first script this is true, and if I press enter when the warning row is shown nothing happens;

In the second script, if I press enter with the warning output, it is actioned passing along an empty argument.

 

the difference between the two script filters are:

The first script filter has an "Argument required" option, because I must start to type to filter the CSS property

The second has an "Argument optional" option, because I must immediately show the possible values for the CSS property selected on the previous script filter, but this option seems to make that the "warning" row can be actioned even if it has no "arg" on its JSON.

 

so summarizing: it's wrong to assume that an output from Alfred can't be actioned if its "arg" is empty?

Is there a way to show a single output item that can't be actioned? 

 

Hope the question is clear, but I'm afraid not

 

    Giulio

Edited August 2, 2016 by juliosecco

[deanishe]

EDIT: For anyone reading this post, it's wrong! This is what Alfred-Workflow does, not Alfred. You must set valid=false to make a result item unactionable!

 

so summarizing: it's wrong to assume that an output from Alfred can't be actioned if its "arg" is empty?

I think that the incorrect assumption is that an empty arg is equivalent to no arg. It's not.

If you do not specify arg in your JSON (or XML), then you have an unactionable result. If you set arg to an empty string, then you just set arg to an empty string… The item is actionable, and Alfred will dutifully pass along the empty string to the next action.

The same goes for autocomplete (if it's an empty string, TABbing deletes the query back to the keyword).
 

Is there a way to show a single output item that can't be actioned?

Setting valid to false should do the trick, but as noted, ensuring arg is not set at all (as opposed to set to an empty string) gives you an unactionable result.

 

So, if any authors of Go libraries for Alfred are reading this: Yup, you've done the JSON wrong, and you'll have to rewrite using pointers to strings

Edited August 7, 2016 by deanishe
Point out wrongness

[juliosecco]

I think that the incorrect assumption is that an empty arg is equivalent to no arg. It's not.

If you do not specify arg in your JSON (or XML), then you have an unactionable result. If you set arg to an empty string, then you just set arg to an empty string… The item is actionable, and Alfred will dutifully pass along the empty string to the next action.

 

deanishe,

 

but in my case I'm not outputting an empty arg, I'm not puttin arg at all in my JSON, so it shouldn't be actionable, true?

when I said 'arg is empty' I was incorrect, I should have wrote arg is absent

and the strange thing is the different behaviour in the 2 script filters, depending on the "Argument required" or not setting...

anyway,

setting valid to false does the trick,

 

so THANK YOU as usual  

Edited August 3, 2016 by juliosecco

[deanishe]

Alfred's letting you action an item with no arg? Is valid also unset?
 
If so, that sounds like it might be a bug. If neither arg nor valid are set, the item should be unactionable.

[juliosecco]

Alfred's letting you action an item with no arg? Is valid also unset?

 

If so, that sounds like it might be a bug. If neither arg nor valid are set, the item should be unactionable.

 

Yes, I confirm.

It seems that if I output an item without 'arg' and 'valid' in a 'script filter',

the item is not actioned if 'Argument required' is set, actioned if 'Argument optional' is set.

setting valid to false is required to be sure the item can't be actioned, as you suggested me.

 

I want to create a test workflow to isolate the behaviour, since mine has become quite complicated

 

If confirmed, do you think I should segnalate this as a bug?

Edited August 3, 2016 by juliosecco

[deanishe]

At any rate, I suppose Script Filter results should behave the same regardless of whether an argument is required or not and regardless of whether they're a top-level or a nested Script Filter.

 

So, yeah, I'd say it's a bug and worth reporting.

[juliosecco]

At any rate, I suppose Script Filter results should behave the same regardless of whether an argument is required or not and regardless of whether they're a top-level or a nested Script Filter.

 

So, yeah, I'd say it's a bug and worth reporting.

I can confirm the thing,

and made a bug report