go-vikunja / vikunja

Mirror of vikunja from https://code.vikunja.io/api
GNU Affero General Public License v3.0
1.02k stars 71 forks source link

Filter with multiple `in` conditions for the same property breaks #346

Open Ma27 opened 2 weeks ago

Ma27 commented 2 weeks ago

Description

Given the following filter

labels in Foo || (labels in Recurring && dueDate < now+10d)

I get the following error:

The task filter value 'Recurring' for field 'labels' is invalid.

I added a log.Warningf statement to the code and it gives me

Nov 05 16:17:36 vikunja vikunja[17088]: 2024-11-05T16:17:36Z: WARNING        ▶ 143 haiya strconv.ParseInt: parsing "Recurring": invalid syntax

The workaround for me was to write labels in <id of label 'Recurring'> and the filter works as expected. When re-opening the filter editor, I even get label in Recurring rather than label in 8 shown.

Vikunja Version

0.24.4

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes.

Screenshots

No response

kolaente commented 2 weeks ago

Are you using this in the API or in the web UI?

Ma27 commented 2 weeks ago

Are you using this in the API or in the web UI?

Reproducible via the browser, haven't tested the API.

kolaente commented 2 weeks ago

If you filter only for Recurring, does it work?

Trying to find out if the label is the problem, or the parentheses.

Ma27 commented 2 weeks ago

Trying to find out if the label is the problem, or the parentheses.

It doesn't seem related to the parentheses: when doing labels in label || labels in label on the demo instance, you'll get the same error.

If you filter only for Recurring, does it work?

Yes.

But keep in mind, I can work around the problem by doing labels in label1 || (labels in N && <another condition here>) where N is the database ID of the second label I want to filter.

kolaente commented 2 weeks ago

Sounds like this only happens with multiple in clauses. I'll take a look.

The api requires ids for the filter, hence the frontend will translate the string labels to ids before making the request. It seems like that's where the problem happens.