Здравствуйте! Хочу предложить исправить ошибку:

1) Что за ошибка, как она возникает:
При ручном исправлении Имени Фамилии или Отчества в лиде или в контакте, при последующем обращении клиента, если в открытые линии передаются другие данные, то ФИО уже существующего контакта изменяется - это недопустимо!
-например на "Гость" (безымянные в Яндекс Чате, Viber, Telegram),
-"Subscriber" (Подписчики в Viber),
-или какой-либо ник Kot123 (Telegram),
-кроме того иногда люди пишут либо с фейковых, либо с чужих аккаунтов соцсетей (вконтакте, фейсбук) например пишет Мария, а представляется Василием (естественно мы вносим то имя, которым человек представился) - у нас это крайне часто, т.к. пишут нам люди с погонами - а многим из них запрещено иметь соцсети

2) Как должно быть - Битрикс не должен изменять имена существующих контактов!

3) Как это сделать? - Запретить изменение Битриксом имени фамилии отчества для контактов, где был ручной ввод! Если ручного ввода не было, и оператор сливает два лида с одноим контактом - давать выбор. Например Написал человек Иванов Пётр с вк и лид сконвертировали в контакт, а потом оказывается человек писал ещё и с facebook где там он представился как Ivanov Petr(Или Вася Пупкин), вот здесь нужно дать оператору выбор какое имя сохранять, а не переделывать постфактум

Обнаружили ошибку при создании лида в Открытых линиях: лид подтягивает в поле "телефон" любое число из текста обращения".
Следующий клиент, который делает аналогичный запрос, уже не создаёт лид, а подхватывается в уже существующий с неправильным "телефоном".


Такой подход в корне неправильный, особенно если часто будут запрашивать популярную модель по артикулу.

Добрый  день! есть вопрос по правам доступа. Представьте клиента (партнера  компании), который может общаться как с руководителем компании, так и с  отдельными менеджерами. С руководителем он может общаться на  конфендициальную тему (например закупочный прайс -лист), но в тоже время  общаться с менеджерами по рабочим вопросам. Т.к. этот клиент (партнер)  пишет с одной и той же почты, то при поступлении письма на адрес  менеджера также создается лид. Далее мы получаем два контакта у которого  два ответсвенных лица (руководитель и менеджер) , но При этом в ЛЕНТЕ  CRM любого из этих созданных контактов видна вся история переписки!!!  Т..е менеджер видит все о чем разговаривал его руководитель с этим  человеком! Нужно установить иерархию прав доступа в лентах CRM, либо не объединять контакты с разными ответственными пользователями.

Строка быстрого Фильтра/поиска на https://idea.1c-bitrix.ru работает ТОЛЬКО по заголовкам и точно по введенному слову. Например, необходимо найти идеи, где есть что-то про роли, чтобы не плодить лишние.
Надо вводить разные слова для получения идей: РОЛЬ, РОЛИ, РОЛЕЙ и это если нет ошибки. Уверен, что это ошибка, а не идея.

Если осуществлять поиск находясь в категории, например, https://idea.1c-bitrix.ru/category/bitrix/ - он работать не будет.

В админке при входе на страницу просмотра/редактирования заказа он грузился довольно долго, но несколько версий назад были внесены изменения, которые подразумевали подгрузку списка товаров заказа отдельным ajax запросом, что значительно ускорило время генерации страницы, но добавило головной боли.

Суть в следующем.
Представим себе довольно крупный ИМ и ситуацию, когда в заказе более 100 наименований.
При входе на страницу редактирования заказа, она сама по себе загружается довольно быстро, но потом стартует процесс подгрузки списка товаров через ajax, на что может уходить несколько секунд.
Так вот, если в этот момент нажать на кнопки Сохранить/Применить/Пересчитать заказ, то список товаров не передастся и вылезет ошибка "Необходимо добавить хотя бы один товар".

Собственно, идея в том, чтоб блокировать эти кнопки пока заказ полностью не прогрузился

Добрый день!

Собственно, все описано в заголовке. Поиск - это минимум, желаний гораздо больше.
Эти идеи ценны не только для компании Битрикс, но и для тех, кто хочет и может менять в коробке.  В общем, пропадает много ценного материала.

Сабж, собственно:
На главной странице он работает, но на практике - не удобен.

На любой внутренней - просто не работает.
Вот пример работы поиска:
1. Открыл раздел "В работе" - вижу список идей: https://i.gyazo.com/feb17be1bd35d7ddffd20970fde6a67c.png
2. Ввел в строку поиска запрос - результат нулевой: https://i.gyazo.com/87366595200b8e6bffd6a8b26ce4b0a5.png
3. Стер запрос - страница не обновилась - результат нулевой: https://i.gyazo.com/34e85fc9c35422becb8e800d76466166.png

Спасибо за внимание.

Б24 уменьшает время на 1 час, полоска не доходит до последнего указанного часа!
И кнопка названа неправильно для сохранения: надо не "Редактировать", а "Сохранить".

Не знаю для чего так сделано, но если открыть карточку исходящего звонка из вкладки "Мои дела", то карточка откроется и ссылка на Клиента будет активной. Если же карточку исходящего звонка открыть из Ленты, то гиперссылка на карточку клиента исчезает:

Прошу поддержать решение данной проблемы:

Работаем с компаниями, у которой много сотрудников, но у них один многоканальный номер. т.е.:

1. У нас создана карточка компании в нее внесен общий номер.
2. У нас есть 50 сотрудников (Клиентов) этой же компании, в карточках сотрудников один и тот же номер.

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

Если менеджер звонит из конкретной карточки Клиента, то исходящий звонок должен быть привязан к этой карточке а не пойми к кому!

Используя стандартные функции Битрикса get_cookie и set_cookie, столкнулся с проблемой, что сохраняется только первое установленное значение (либо первые несколько), а потом перезапись куки умирает.

Проблема оказалась в том, что куки для основного домена .site.ru перезаписывается, а для домена .www.site.ru нет.

Сайт доступен в обоих вариантах, как с www, так и без. Сайтов в Битриксе 1 штука. В этом сайте прописан один домен. Домен прописан как site.ru. В настройках главного модуля стоит галка "Распространять куки на все домены". Ошибка воспроизводится именно в такой конфигурации с заходом на www.site.ru

Оперативный вариант избавиться сейчас от ошибки на ядре 15.0.6 состоит в изменении конфигурации: либо убираем галку "Распространять куки на все домены", либо удаляем все домены в настройках сайта.
Но тут всплывут проблемы в виде уже установленных у пользователей кук на домены, которые могут перетирать устанавливаемые на новой конфигурации куки, и тогда некоторый функционал, связанный с куками, вообще перестает работать для таких пользователей.

Сама суть ошибки в том, что /bitrix/spread.php не выдает в заголовках куку для домена www.site.ru.

Поиск проблемы:
1. md5 в spread.php и передаваемый в параметре $_GET["k"] md5 не совпадают
2. т.к. соль $salt генерируется на стороне php, то проблема не в ней, а в переменной $cookie, которая передается в виде закодированной base64 строки
3. в самом запросе видим что-то типа /bitrix/spread.php?s=QklUU_тут_было_много_букв_BAg%253D%253D&k=af5a0ce9b001a018cb7a98fc26579cec
Интересует нас неправильное окончание параметра s, %253D%253D
4. Поиски доков по функции base64_decode приводят на официальный сайт php: http://php.net/manual/ru/function.base64-encode.php
Где в первом же комментарии видно, что есть вариации в виде base64url_encode для безопасной передачи таких параметров через url.
5. Далее идем патчить ядро:
Ищем функцию GetSpreadCookieUrls() в файле /bitrix/modules/main/classes/general/main.php
и в ней заменяем base64_encode на base64url_encode, предварительно записав функцию base64url_encode в /bitrix/php_interface/init.php
6. В файле /bitrix/modules/main/spread.php прописываем функцию base64url_decode и заменяем вызов base64_decode на base64url_decode
7. Проверяем, теперь проблемы нет и куки устанавливаются нормально!

Прошу поправить ошибку в ближайших апдейтах ядра, т.к. ошибка значительная, и подозреваю что в ядре она очень давно.

Столкнулись с такой моментом

Пользователь может просто зарегистрироваться на сайте и авторизоваться через соц сеть

На сайте стоит проверка на уникальность email'a.
В случае если такой email уже есть на сайте, а затем пользователь авторизуется/регистрируется через соц сеть, то спокойно создается второй аккаунт с такой же почтой.

Было бы не плохо избежать данного бага и при наличии пользователя с такое же почтой привязывать его к уже существующему аккаунту

Есть такая проблема с поиском

Например ищем "Смартфон HTC One M8 16GB Grey"
Вводишь "htc" - находит
Вводишь "htc m8" - не находит
Вводишь "htc m8 one" - находит

косяк в том, что для htc m8 определяется более вероятный вариант "рес ь8"

Соответственно, есть предложение
Может быть есть смысл использовать поисковый индекс как источник для расчета вероятности искомых словосочетаний.

Иначе мы получаем неэффективный в некоторых случаях поиск.

Есть и второй вариант - реализовать в компонентах повторный поиск с использованием исходного запроса, как я сделал сейчас.
Но это сказывается на производительности.