Сообщений в теме: 17

[SigMA]

Возможно ли вынести дополнительные парметры формирования отчета на закладку Просмотр (или может быть по-другому это реализовать).

Расшифровка вопроса.
Допустим, мы хотим наложить на выбираемые отчетом данные какие-то условия (автор(ы), ответственный(ые), дата создания/последнего изменения и т.п. ).

Понятно, что это, в принципе, можно сделать через фильтр. Но это не очень удобно
1. Если фильтр публичный, изменения фильтрования отразятся на всех.
2. Лишние телодвижения.

Вот если бы в фильтре можно было указать (это я фантазирую :) ), что по такому-то реквизиту можно накладывать условия непосредственно при формирования отчета, то это было бы очень даже неплохо.

Возможно такое? (Боюсь, я даже знаю ответ :( )

[barancev]

Да, только через фильтр.

[SigMA]

Все понятно.
Спасибо.

Алексей, в свое время Вы говорили, что имеете некоторое влияние на разработчиков. Нельзя ли донести до них эти вопросы. Может быть в новых изданиях они учтут пожелания простых пользователей этой системы.

[barancev]

Я попробую :)
Но в данном случае лично мне кажется, что всё достаточно удобно. На то и фильтры.

[SigMA]

Я попробую :)

Спасибо.
Учтите еще, пожалуйста, вопросы, поднятые в предыдущих темах
("TrackStudio. Отчеты. Проблема с группировкой" и "TrackStudio. Выбор ответственного")

Но в данном случае лично мне кажется, что всё достаточно удобно. На то и фильтры.

Не согласен. Причины привел в исходном сообщении.

Это неудобно, т.к. вместо того, чтобы в одном месте настроить условия для формирования отчета и сразу же его получить, надо зайти еще в фильтры и среди всех реквизитов найти нужные и выставить их. Потом идти в отчеты и уж отуда выполнять. А если это надо делать многократно?

С этим неудобством можно было и смириться, но вот то, что при изменении фильтра (если он публичный) это отражается на всех - это недопустимо. Если одним и тем же отчетом одновременно пользуются несколько пользователей - результат отчета может их неожиданно "порадовать".

[maximkr]

На самом деле пользователи спрашивают эту фичу довольно часто - имеет все шансы появиться в 3.2 или 3.3.

PS. А чем простые пользователи отличаются от не очень простых ? :-)

[Dmitry_NJ]

PS. А чем простые пользователи отличаются от не очень простых ? :-)

Количеством денег, которые они уже потратили на ваши продукты/сервисы, и потенциальной возможностью продолжать делать это и в будущем.

[maximkr]

PS. А чем простые пользователи отличаются от не очень простых ? :-)

Количеством денег, которые они уже потратили на ваши продукты/сервисы, и потенциальной возможностью продолжать делать это и в будущем.

В нашем случае большой разницы нет: продукт относительно дешевый и нет смысла покупать более 1 копии на компанию, поэтому все клиенты более-менее равноценны и каждый клиент в отдельности мало влияет на прибыль.

Пожалуй, главный критерий делать/не делать - это полезность фичи большому количеству пользователей и ее соответствие концепии продукта.

[SigMA]

На самом деле пользователи спрашивают эту фичу довольно часто - имеет все шансы появиться в 3.2 или 3.3.

Спасибо.
А когда планируется выход этих версий?

[maximkr]

Спасибо.
А когда планируется выход этих версий?

3.2 - осень 2005
3.3 - весна 2006

[maximkr]

Вот если бы в фильтре можно было указать (это я фантазирую :) ), что по такому-то реквизиту можно накладывать условия непосредственно при формирования отчета, то это было бы очень даже неплохо.

Возможно такое? (Боюсь, я даже знаю ответ :( )

Собственно в 3.2 уже вышла и там это было сделано. Я помню, что Вас с 3.2 были проблемы, они уже решены, но теперь лучше подождать 3.5 (ожидается в течении нескольких недель).

[SigMA]

Вот если бы в фильтре можно было указать (это я фантазирую :) ), что по такому-то реквизиту можно накладывать условия непосредственно при формирования отчета, то это было бы очень даже неплохо.

Возможно такое? (Боюсь, я даже знаю ответ :( )

Собственно в 3.2 уже вышла и там это было сделано. Я помню, что Вас с 3.2 были проблемы, они уже решены, но теперь лучше подождать 3.5 (ожидается в течении нескольких недель).

[SigMA]

Вот если бы в фильтре можно было указать, что по такому-то реквизиту можно накладывать условия непосредственно при формирования отчета....

Собственно в 3.2 уже вышла и там это было сделано. Я помню, что Вас с 3.2 были проблемы, они уже решены, но теперь лучше подождать 3.5 (ожидается в течении нескольких недель).

Что с отчетами поправили, это хорошо (правда пока на это внимание не обратил).
Вот только, в остальном, работа с фильтрами, к сожалению, не улучшилась, а только ухудшилась.
Если честно, с ними очень неудобно работать. Особенно на больших объемах или при использовании скриптов - очень низкая производительность получается.
Вам вроде все замечания, как по 3.1, так и по 3.2 должны были передать.

[maximkr]

Что с отчетами поправили, это хорошо (правда пока на это внимание не обратил).
Вот только, в остальном, работа с фильтрами, к сожалению, не улучшилась, а только ухудшилась.
Если честно, с ними очень неудобно работать. Особенно на больших объемах или при использовании скриптов - очень низкая производительность получается.
Вам вроде все замечания, как по 3.1, так и по 3.2 должны были передать.

Вы имеете в виду выполнение "перефильтрации" после заполнения каждого параметра ?

На самом деле в 3.2/3.5 производительность фильтров должна улучшится в разы:
1) Сделали предварительную инициализацию кешей. Т.е. 3.2 умеет заранее определять каких данных нет в кеше, готовит 1 (сложный) запрос и достает их за 1 раз. Это должно значительно улучшить скорость работы если нужна фильтрация по невычисляемым custom fields.
2) Для вычисляемых custom fields сделали кеширование результата вычисления (поле можно отметить как кешируемое если результат не зависит от других задач).

Еще в 3.5 появится такое:
3) Возможность full text search не через фильтры, а через поле ввода в правом верхнем углу.
4) Появились обратные ссылки, т.е. если задача A ссылается на задачу B, то при переходе на задачу B сразу будет видно кто на нее ссылается. Фича должна упростить создание зависимостей между задачами.

Давайте дождемся 3.5 и если там с производительностью все равно будут проблемы - будем думать.

[SigMA]

Вы имеете в виду выполнение "перефильтрации" после заполнения каждого параметра ?

Да.

На самом деле в 3.2/3.5 производительность фильтров должна улучшится в разы:
Давайте дождемся 3.5 и если там с производительностью все равно будут проблемы - будем думать.

Хорошо.
Только мне кажется, все-таки правильнее было бы сначала за один заход определять все необходимые критерии поиска, а потом уже фильтровать.
Ну, и раз уж я с Вами тут пересекся, выскажу еще пожелания.
1. При поиске по номеру (в глобальном писке и по фильру) было бы удобне, если бы искомые номера задач можно было бы задавать перечисленим, интревалом и т.п. А то при существующей системе получается, если хочешь посмотреть несколько задач, каждую приходится искать отдельно - неудобно.

2. Очень неудобно искать задачу для прикрепления в пользовательское поле типа задача. там очень не хватает поиска по номеру задачи. Для того, чтобы найти задачу, надо отыскать ее в списке задач по какому-то фильтру. Если в фильтр попадает много задач, то операция становится очень трудоемкой. Тем более, если эта операция часто повторяющаяся.
Кроме того этой операции прикрепления напрягает двойное поддтверждение. Сначала надо выбрать из общего списка и передать в список выбранных задач, а потом еще раз отметить в списке выбранных задач и только потом поддтвердить выбор. Мне кажется вторая операция является лишней - очень неудобно.

[maximkr]

Вы имеете в виду выполнение "перефильтрации" после заполнения каждого параметра ?

Да.

Это не стали делать - сделать сложно из-за AJAX, а за счет ускорения фильтрации польза от этой фичи должна стать минимальной.

Ну, и раз уж я с Вами тут пересекся, выскажу еще пожелания.
1.  При поиске по номеру (в глобальном писке и по фильру) было бы удобне, если бы искомые номера задач можно было бы задавать перечисленим, интревалом и т.п. А то при существующей системе получается, если хочешь посмотреть несколько задач, каждую приходится искать отдельно - неудобно.

ОК, посмотрим на эту проблему еще раз. Возможно, в 3.5 будет.

2. Очень неудобно искать задачу для прикрепления в пользовательское поле типа задача. там очень не хватает поиска по номеру задачи. Для того, чтобы найти задачу, надо отыскать ее в списке задач по какому-то фильтру. Если в фильтр попадает много задач, то операция становится очень трудоемкой. Тем более, если эта операция часто повторяющаяся.
Кроме того этой операции прикрепления напрягает двойное поддтверждение. Сначала надо выбрать из общего списка и передать в список выбранных задач, а потом еще раз отметить в списке выбранных задач и только потом поддтвердить выбор. Мне кажется вторая операция является лишней - очень неудобно.

Это все решено в 3.5 - там внешний вид окна для выбора задач поменялся и теперь можно искать по номеру. Более того, если номера задач известны - их можно ввести прямо в поле ввода (как для custom fields типа String), при этом окно для выбора задач использовать не нужно.

[SigMA]

Вы имеете в виду выполнение "перефильтрации" после заполнения каждого параметра ?

Это не стали делать - сделать сложно из-за AJAX, а за счет ускорения фильтрации польза от этой фичи должна стать минимальной.

Жаль, но посмотрим, что получится.

1.  При поиске по номеру (в глобальном писке и по фильру) было бы удобне, если бы искомые номера задач можно было бы задавать перечисленим, интревалом и т.п. А то при существующей системе получается, если хочешь посмотреть несколько задач, каждую приходится искать отдельно - неудобно.

ОК, посмотрим на эту проблему еще раз. Возможно, в 3.5 будет.

Попробуйте ее решить, было бы очень полезно.

2. Очень неудобно искать задачу для прикрепления в пользовательское поле типа задача. там очень не хватает поиска по номеру задачи. Для того, чтобы найти задачу, надо отыскать ее в списке задач по какому-то фильтру. Если в фильтр попадает много задач, то операция становится очень трудоемкой. Тем более, если эта операция часто повторяющаяся.

Это все решено в 3.5 - там внешний вид окна для выбора задач поменялся и теперь можно искать по номеру. Более того, если номера задач известны - их можно ввести прямо в поле ввода (как для custom fields типа String), при этом окно для выбора задач использовать не нужно.

Это замечательно.
Будем с нетерпением ждать 3.5. И, надеюсь, с ней не будет такого разочарования, как с 3.2

[maximkr]

1.  При поиске по номеру (в глобальном писке и по фильру) было бы удобне, если бы искомые номера задач можно было бы задавать перечисленим, интревалом и т.п. А то при существующей системе получается, если хочешь посмотреть несколько задач, каждую приходится искать отдельно - неудобно.

Я только хотел сказать что 3.5 вышла и там эта фича есть, можно указывать номера в виде 1,3,5-10