В справке для поиска есть описание следующего параметра: Поле Имена полей для поиска Дней с последнего изменения ошибки days_elapsed Если в поиске вбить "days_elapsed:1000", то в результатах поиска будет только несколько багов от 2022 года. А если "days_elapsed:10" - поиск выводит большой список багов, от тех, которые были изменены 10 дней назад до тех, которые последний раз изменялись в 2008 году. Ожидаемый результат: при поиске по параметру days_elapsed:N выводятся те ошибки, которые последний раз изменялись N дней назад.
Разобрались, в чём дело: в быстром поиске синтаксис «поле:значение» по умолчанию ищет подстроку, и days_elapsed не исключение — число дней с последнего изменения сравнивается со значением как строка. Поэтому days_elapsed:10 находит все баги, у которых в числе дней встречается «10» (10, 100–109, 210, 1023, 6104…), а days_elapsed:1000 — только те, где встречается «1000». Уже сейчас работают числовые операторы: days_elapsed<10 — изменялись за последние 10 дней days_elapsed>1000 — не менялись больше 1000 дней Хотим починить поведение записи days_elapsed:N через двоеточие и выбираем семантику. Варианты: 1. «ровно N дней назад» (equals) — буквально то, что описано в справке, но на практике почти бесполезно; 2. «изменялись за последние N дней» (<=) — самый ходовой сценарий; 3. «не менялись дольше N дней» (>) — так в апстриме сделан похожий параметр owner_idle_time. Какое поведение было бы удобнее для вашей задачи? Мы склоняемся к варианту 2, а точные диапазоны всегда можно задать операторами < и >.
> Какое поведение было бы удобнее для вашей задачи? Какой-то конкретной задачи нет, я смотрела на этой с т.з. пользователя, который хочет найти ошибки с фильтром по изменениям. > «изменялись за последние N дней» (<=) — самый ходовой сценарий; > Мы склоняемся к варианту 2, а точные диапазоны всегда можно задать операторами < и >. Думаю, лучше так и сделать, просто дополнительно подправить справку для days_elapsed, чтобы она отражала реальное поведение.
