Saved filters broken by recent update to 2018.2

Over the weekend, our YouTrack InCloud instance updated to 2018.2 Build 42133. We came in this morning and several of our filters were broken. From testing, it looks like the queries have gotten significantly stricter and I'd like to know if the following are by-design or if this is unexpected behavior:

  1. Filters containing "#Unassigned" stopped working. It turned out that we had fields in various projects that had "Unassigned" as a value (or empty value) and that YouTrack got confused when doing a search like "project: MYPROJ #Unassigned" in that it returned nothing. It looks like #Unassigned was finding values in a certain field and if the specified project did not contain that field, it just returned nothing. Renaming some of the Unassigned values fixed this problem.
  2. We had our system setup so that the Stage field and the State field had aliases for each other. When searching for "State: Fixed", it would also return nothing when paired with a project (e.g. "project: MYPROJ State:Fixed"). This was fixed by removing the alias from Stage corresponding with State.
  3. EDIT: Also, when doing a find like "project: MYPROJ #Fixed" where the project contains multiple fields that contain the value "Fixed", YouTrack now seems to choose one of those fields and only return results for that field instead of returning results for any field that contains that value.

Basically, YouTrack, when not limiting searches by selecting a scope in the drop-down seems to decide what field a certain value belongs to and even when specifying a certain project, the correct field/value combination for that project is not used.

 

6 comments
Comment actions Permalink
Official comment

Hello,

It seems like you have a few entities with the same name and they were selected by chance by YouTrack, we didn't change anything about search in the upgrade, so most likely mechanism just changed the selection principle on his own.  

Comment actions Permalink

Basically this change results in no two fields being able to have the same name for a value. If that is true, shouldn't that be reinforced somehow when creating the field values? Otherwise, this behavior is completely transparent when searching.

0
Comment actions Permalink

Why it should be reinforced? It's not prohibited to create the same value for the different fields.

0
Comment actions Permalink

Maybe I'm blowing this completely out of proportion, but if using the '#' notation in a query doesn't produce consistent results because it may pick a field that is unrelated to the project you are searching (number 1 and 3 in my first comment), it seems like we need to keep each field from having identical values so that it will work as would be expected.

The same thing applies to aliases. If we can't have an alias for a different field because the query may pick the wrong field when doing a search in a project (number 2 in my first comment), we are then required to have no aliases with the same name as another field.

0
Comment actions Permalink

I'm sorry for  the misleading, we've confirmed it as a bug, the bug fix is ready and waiting to be released. 

0
Comment actions Permalink

Okay, thanks for the information. I was beginning to wonder if we were the only ones having these problems. :)

0

Please sign in to leave a comment.