Михаил Турунов написал: Есть информация от коллег о наличии аналогичной проблемы!
Эти коллеги использовали ту же инструкцию что и вы? Или быть может настраивали вам? Просто у нас на РедОС сервера есть и такой ситуации не наблюдаем. Посмотрите логи за это время, может быть что-нибудь происходит
Здравствуйте. В любом случае готовых открытых решений нет, но есть +-готовые подсистемы у разных участников рынка.
Все начинается с того что именно вы хотите от KeyCloak - он должен выступать поставщиком пользователей (т.е. при авторизации нужно проверять наличие и если есть - создавать) или только сервером авторизации (проверять аутентифицировать и если все ок авторизировать). Самый простой вариант - выставить KeyCloak как сервер авторзиации и подключить его к битрику как коннектор к соц.сервисам.. Документации на эту тему конечно же никакой, да и требуется наличие модуля соц.сервисов.
Отправной точкой могут послужить классы из: /bitrix/modules/socialservices/classes/
Игорь Александрович написал: Есть ли еще зависимости в базе данных по руководителям подразделения?
Руководители подразделений хранятся только там. После ваших манипуляций необходимо сделать следующее: 1. Сбросить кеш портала (в административной панели). 2. Сбросить кеш прав сотрудника, проще всего кодом в консоли:
123 - идентификатор сотрудника.
Код
$access = new CAccess();
$access->UpdateCodes([
'USER_ID' => 123
]);
globus, ну вообще VM не поддерживает резервирование балансировщика, так что придется поддерживать его самостоятельно. Можете собрать отказоустойчивую архитектуру самостоятельно без VM.
Александр Каменский написал: О данной технологии очень мало информации (отзывов, обсуждений) и хотелось бы узнать мнение людей кто использует данное решение, особенно интересны сайты с большими каталогами.
О данной технологии мало информации по двум причинам: потому что мир ушел в другом направлении и потому что во всем мире она называется немного иначе. Собственно основной мир уже ушел в сторону разделения между фронтендом (публичная часть для пользователей) и бекендом (административный интерфейс и api), так что если хотите действительно реального профита то стоит смотреть уже в эту сторону.
Собственно технология это своего рода попытка принести плюшки мира разделения в мир битрикса не нарушая его концепцию. На мой взгляд получилось немного не удачно - в целом работает, но она требует значительных временных затрат на настройку и разработку.
Сергей Зверев написал: При активаций модуля выводить ошибку: Ошибка активации купона: [CHECK_ACTIVATE_ERROR] ActivateCheck: You should buy module before update. Ошибка активации купона.
Из-за чего ошибка и Что делать?
Модуль входит в вашу лицензию? Возможно у вас была более старшая версия, а потом вы решили понизить и каким-то образом получилось понизить без удаления, а теперь активируете модуль.
На текущий момент битрикс не работает с minio, за счет того что он хоть и s3-compatible, но подпись (signature) считает не так как это делает AWS S3/Y.OS/mail.ru и т.п. Нам для этого пришлось писать свой коннектор на базе aws s3 с правками под minio.
Евгений Осипов написал: В консоли записи:Pull: Websocket connection with push-server closed. Code: 1006, reason:
Откройте консоль браузера при открытии страницы, посмотрите что вернет XHR запрос с pull.config. Сравните с тем что есть в настройках (возможно подпись не так или пути). Проверьте что между вами и сервером нет реверс-прокси (если они есть - нужно их сконфигурировать чтобы они пропусками websocket соединения).
Цитата
Евгений Осипов написал: В целом всё работает нормально, но каждые 30 секунд пишет сначала:Отсутствует соединение с сервером
Это означает что настройка не завершена или некорректна. Push-часть портала перешла из режима websocket в режим longpolling (30 секунд отката) и поэтому при переподключениях возникает подобная ошибка.
И сделайте ограничения в фильтре: USER_ID - идентификатор пользователя (кому назначеное задание) STATUS - статус задания DOCUMENT_ID - идентификатор документа по которому запущен БП MODULE_ID - идентификатор модуля для которого запущен БП ENTITY - код сущности для которой запущен БП WORKFLOW_TEMPLATE_ID - идентификатор шаблона бизнес-процесса (WORKFLOW_TEMPLATE_NAME - название шаблона бизнес-процесса)
Важные сообщения: новым пользователям показываются все предыдущие важные сообщения в статусе "не прочитано", Важные сообщения: новым пользователям показываются все предыдущие важные сообщения в статусе "не прочитано". В результате необходимо "отщелкать" много сотен уведомлений, чтобы видеть только "свежие". Из-за отображения всех формируется привычка видеть вися
Иван Дворковой написал: Здравствуйте.Подскажите, как-то решили свою проблему?
Мы решили проблему так: один раз прошлись по записям и проставили им "Дату окончания важности сообщения" (b_uts_blog_post - UF_IMPRTANT_DATE_END) С тех пор - при написании важного сообщения - всегда ставим дату окончания важности.
Евгений Васьков написал: Помогите пожалуйста разобраться где я допускаю ошибку?
Попробуйте создать переменную с тем же типом (привязка к элементам СРМ) и посмотреть что получается после вашего merge (используйте логгирование в журнал). Скорее всего он отрабатывает некорректно.
Людмила написал: Есть созданный список (но аналогичная проблема наблюдается и в бизнес процессах).
Я располагаю только коробкой и увы, у меня нет типа "Привязка к элементам инф.блоков", поэтому особо сильно помочь не смогу.
Цитата
Людмила написал: В список добавляются элементы, потом удаляются. много и часто. Но! Когда я этот список пытаюсь отображать пользователю через БП "Привязка элементов инфо блоков" - то там я вижу абсолютно старый набор записей.
Мне кажется, что если у вас происходит изменение списка довольно частые, то скорее всего где-то что-то не так. Не думаю что в текущих механиках Битрикс24 предусмотрены частые изменения список, поэтому скорее всего там заложен механизм кеширования где-нибудь на час или сутки (обычно стандартные интервалы кеширования).
Попробуйте перестроиться таким образом чтобы этот список не менялся так быстро.