Очень бы хотелось условное форматирование по типу Эксель, Акцесс. Если поле имеет такое то значение, то стиль такой то (и там фон задаем, шрифт, размер, цвет, если смущает прям совсем вольные стили сделать хотя бы фон и цвет текста чтобы можно было менять), если поле пустое и т.д. (условия как в фильтрах задач например).
Очень не хватает. В гигантских простынях все сливается, а нужно видеть — где не заполнено и т.д. Лучший способ — выделить цветом.
Условное форматирование для полей
-
- Сообщения: 460
- Зарегистрирован: 23.05.2013 21:46
-
- Сообщения: 61
- Зарегистрирован: 26.04.2016 20:46
-
- Сообщения: 460
- Зарегистрирован: 23.05.2013 21:46
-
- Сообщения: 171
- Зарегистрирован: 19.01.2016 18:50
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
-
- Сообщения: 117
- Зарегистрирован: 07.09.2016 07:56
-
- Сообщения: 248
- Зарегистрирован: 30.03.2016 16:58
Поддерживаю идею, высказанную Андреем Гринюком.
Но я вот что подумал. Формализовать данный вопрос во широком многообразии его проявлений и потом воплотить это в виде удобных визуальных средств — это весьма серьёзная задача. Да, поставить в качестве примера реализацию условного форматирования в Excel нетрудно, но вспомните хорошенько, сколько всяких мелочей она включает и при этом местами остаётся неудобной.
Я это к чему.
Мы, безусловно, будет рады увидеть встроенное в Планировщик средство настройки условного форматирования полей. Но на данный момент его нет не будет скоро, как сказал Дмитрий, а многим хочется.
При этом, написать браузерный скрипт, который будет обрабатывать отображаемые значения полей в карточках и выполнять нужное в конкретном случае форматирование, способен любой мало-мальски вменяемый javascript-программист за бутылку лимонада. К тому же, скрипт может быть оформлен в формате для скриптовых оболочек Tampermonkey/Greasemonkey, что избавит от необходимости создания собственных расширений для браузера, но при этом сохранит возможность лёгкой установки скрипта любым пользователем Сhrome/Firefox/etc.
На этом "за здравие" заканчиваю.
На пути этого решения сейчас стоит одно фатальное препятствие: в коде страницы поля никак системно не различаются — это просто разные надписи или более сложные элементы, но без какой-либо идентификации природы их данных (я мучительно пытался хоть как-то обойти эту проблему в своих "Нанокарточках" через косвенные отличительные признаки полей).
Поэтому, предлагаю такую идею.
Если уважаемые разработчики не возражают против развития описываемого пути кастомизации Планировщика, то было бы достаточно, чтобы к html-элементу поля в карточке добавился какой-то признак, однозначно идентифицирующий это поле (скажем, к тому div, который имеет класс «task-microcard-block-*» можно добавить html-атрибут вроде «field-name="task-status"»). Конечно, было бы вообще замечательно, если бы у полей, отображающих текстовое представление для нетекстовых данных, где-то в html-атрибутах предоставлялись ещё и значения данных во внутреннем представлении (к примеру, код статуса для статуса задачи). Кстати, у некоторых полей и сейчас есть подобное — скажем, поле "Избранное" имеет атрибут data-starred="<код>". Я уверен, что не ошибусь, предполагая, что все идентификаторы полей и внутренние значения данных проходят на бекенде при формировании html-кода карточки, остаётся только выдать их в виде соответствующих новых html-атрибутов вместе с другими элементами карточки, так что и расходы на доработку, и накладные вычислительные расходы вряд ли будут значительными.
Такой мини-API, с минимумом усилий со стороны разработчиков, даст широкую свободу для мощной кастомизации карточек силами конечных пользователей. Открытые системы — это сила! ;-)
P.S. Свет не сошёлся клином именно на карточках Планировщика. Я о них говорю, потому что насмотрелся на их "потроха". В других местах интерфейса такое, наверное, тоже применимо.
P.P.S. Конечно, скрипт может для идентификации полей привязаться к их текстовым подписям. Но как-то это уж совсем костыльно.
Но я вот что подумал. Формализовать данный вопрос во широком многообразии его проявлений и потом воплотить это в виде удобных визуальных средств — это весьма серьёзная задача. Да, поставить в качестве примера реализацию условного форматирования в Excel нетрудно, но вспомните хорошенько, сколько всяких мелочей она включает и при этом местами остаётся неудобной.
Я это к чему.
Мы, безусловно, будет рады увидеть встроенное в Планировщик средство настройки условного форматирования полей. Но на данный момент его нет не будет скоро, как сказал Дмитрий, а многим хочется.
При этом, написать браузерный скрипт, который будет обрабатывать отображаемые значения полей в карточках и выполнять нужное в конкретном случае форматирование, способен любой мало-мальски вменяемый javascript-программист за бутылку лимонада. К тому же, скрипт может быть оформлен в формате для скриптовых оболочек Tampermonkey/Greasemonkey, что избавит от необходимости создания собственных расширений для браузера, но при этом сохранит возможность лёгкой установки скрипта любым пользователем Сhrome/Firefox/etc.
На этом "за здравие" заканчиваю.
На пути этого решения сейчас стоит одно фатальное препятствие: в коде страницы поля никак системно не различаются — это просто разные надписи или более сложные элементы, но без какой-либо идентификации природы их данных (я мучительно пытался хоть как-то обойти эту проблему в своих "Нанокарточках" через косвенные отличительные признаки полей).
Поэтому, предлагаю такую идею.
Если уважаемые разработчики не возражают против развития описываемого пути кастомизации Планировщика, то было бы достаточно, чтобы к html-элементу поля в карточке добавился какой-то признак, однозначно идентифицирующий это поле (скажем, к тому div, который имеет класс «task-microcard-block-*» можно добавить html-атрибут вроде «field-name="task-status"»). Конечно, было бы вообще замечательно, если бы у полей, отображающих текстовое представление для нетекстовых данных, где-то в html-атрибутах предоставлялись ещё и значения данных во внутреннем представлении (к примеру, код статуса для статуса задачи). Кстати, у некоторых полей и сейчас есть подобное — скажем, поле "Избранное" имеет атрибут data-starred="<код>". Я уверен, что не ошибусь, предполагая, что все идентификаторы полей и внутренние значения данных проходят на бекенде при формировании html-кода карточки, остаётся только выдать их в виде соответствующих новых html-атрибутов вместе с другими элементами карточки, так что и расходы на доработку, и накладные вычислительные расходы вряд ли будут значительными.
Такой мини-API, с минимумом усилий со стороны разработчиков, даст широкую свободу для мощной кастомизации карточек силами конечных пользователей. Открытые системы — это сила! ;-)
P.S. Свет не сошёлся клином именно на карточках Планировщика. Я о них говорю, потому что насмотрелся на их "потроха". В других местах интерфейса такое, наверное, тоже применимо.
P.P.S. Конечно, скрипт может для идентификации полей привязаться к их текстовым подписям. Но как-то это уж совсем костыльно.
-
- Сообщения: 460
- Зарегистрирован: 23.05.2013 21:46
+100. А Кирилл бы нам помог со скриптами :)чтобы к html-элементу поля в карточке добавился какой-то признак, однозначно идентифицирующий это поле (скажем, к тому div, который имеет класс «task-microcard-block-*» можно добавить html-атрибут вроде «field-name="task-status"»). Конечно, было бы вообще замечательно, если бы у полей, отображающих текстовое представление для нетекстовых данных, где-то в html-атрибутах предоставлялись ещё и значения данных во внутреннем представлении (к примеру, код статуса для статуса задачи).
-
- Сообщения: 236
- Зарегистрирован: 29.05.2014 18:14
-
- Сообщения: 492
- Зарегистрирован: 21.01.2018 18:09
Александр, добрый день.Нужно условное форматирование в планировщике, в списках, например, список сделан для задач в статусе новая и принята, группировка по проекту, сортировка по приоритету, но нужно различать в этом списке была ли задача принята исполнителем. Не хочется для этого создавать отдельный список.
Как вариант можно переделать "список задач" в "карточку задачи", и вывести два поля название задачи и статус. Также добавить сортировку по статусу тогда сначала будут "новые", потом "принятые".