Данная идея не является той же что здесь уже есть!
Предлагаю реализовать поддержку данного сервиса внутри БУС (+ Б24). Вопрос оптимизации поиска стоит довольно остро и хотелось бы иметь возможность реально ускорить в несколько раз систему. Плюс самое интересное - это подойдет не только для поиска, но и для вывода например каких-то других данных.
Среди крупных сайтов, использующих Elasticsearch, отмечаются Wikimedia, StumbleUpon, Quora, Foursquare, SoundCloud, GitHub, Netflix. Amazon, IBM, Qbox и компания Elastic предлагают подписчикам Elasticsearch в качестве управляемого сервиса
1. После добавления документа в индекс поиск по этому документу доступен уже менее чем через 1 секунду. 2. Структура хранения данных в Еlasticsearch произвольная, что позволяет хранить документы в удобном, подготовленном виде. 3. Мы используем Еlasticsearch еще и для хранения серверных логов. А выводим их в Kibana. 4. Ну и конечно, Еlasticsearch очень быстр! Запрос для одного раздела обрабатывается за 0,03 секунды.
Часто бывает , нужно найти пароль или сумму или дату или ссылку в переписке с коллегами. Предлагаю сделать функцию "Избранное". Любое сообщение можно сохранить в Избранное (можно через меню, где цитирование). Окно сообщений "Избранное" открывается по аналогии с окном истории сообщений. Важная опция - настройка времени хранения избранного . Каждый пользователь может указать количество дней в течение которых хранятся сообщения в избранном. По умолчанию - 30 дней.
Давно прошу и пишу идеи и обращения, но вдруг... Нужен поиск по ФИО+компания при добавлении связей например задачу привязать к контакту (сменился ответственный менеджер у клиента, нужно в задаче указать..)
При вводе комментариев есть хорошая функция прикрепить файл. И кнопка правильно называется "Найти в Битрикс24", вот только функции поиска там нет - нужно бегать по папкам и самим искать файл. Прямо так и просится поле поиска в диалог. Причём в мобильной версии есть, а в web - забыли
Предлагается при создании и модификации таблиц БИТРИКС проверять возможность добавления типа индексов FULLTEXT , в частности в поисковом модуле есть такие таблицы
например, так выборка таблиц в которые нельзя добавить эти индексы;
SEL ECT TABLE_NAME FR OM information_schema.TABLES where TABLE_SCHEMA =DATABASE() and ENGINE = 'ROCKSDB'
Например, сейчас невозможно поиском найти нужную информацию в комментариях к задачам. То есть, убита возможность находить что-то в истории компании. Тот, кто принял такое решение, абсолютно не понимает, как ваши клиенты используют битрикс24.
Вообще, продакт-менеджерам вся статистика по использованию функциональности и накопленным пользователями данным доступна - все же в облаке - так какого дьявола такой анализ не проводится при принятии решения об изменении доступного функционала? Граждане продакт-менеджеры, такой подход - прямой путь к тому, чтобы убить отличный продукт. И вы на него вступили. Как давно это произошло - не знаю.
У меня сотни свойств товаров и иногда необходимо выяснить, есть ли уже нужное свойство для новой категории товаров или необходимо создать новое. При поиске во вкладке https://yadi.sk/d/EVEIIFOKrATrbw даже существующее свойство находится только при полном совпадении, отличие в один знак или пробел выдаёт результат: ничего не найдено. Это вызывает недоумение, ведь на сайте многое ищется очень неплохо. Точно так же при добавлении необходимых свойств в раздел https://yadi.sk/d/R69319QM86jXkA поиск свойства, которое необходимо добавить, происходит только по символьному коду, а не по названию на русском. Это очень затрудняет работу. Предлагаю сделать внутренний поиск в самой CMS по свойствам на русском или по символьному коду, но умный с неполным совпадением. Это бы очень сильно облегчило работу контент-менеджера и админа.
Сейчас объединение дубликатов идет в определенной сущности: в Контактах отдельно, в Компаниях отдельно.
Предлагаю объединение сделать перекрестным, чтобы участвовало множество сущностей. Зашел поискать дубликаты и, например, нашел, что этот определенный e-mail адрес встречается в Почте, также он прикреплен к такому-то Контакту и он же есть у такой-то Компании.
По ходу промежуточная идея - это адресная книга электронной почты - хорошо бы иметь ее и с ней работать.
Зашел поискать кого-то по имени и фамилии, ага, нашел, далее видишь, что он есть в Контактах, в Адресной книге почты, привязан к такой-то Компании и с ним еще и создана Сделка.
В итоге, чтобы была возможность объединять дубликаты между собой по: Лидам, Контактам, Компаниям, Сделкам, Адресной книге почты и другим сущностям.
Такая же логика может касаться любой коммуникационной зацепки: телефона, участия в чате, в мессенджере, даже социальной сети, если из нее было обращение в Открытую линию.
Не хватает строчки с поиском, чтобы не глазами искать нужное активити, а начать вводить его название и показывались результаты. Нечто подобное реализовано в БУС при редактировании страницы и поиске компонента