Форум

Дмитрий Васильев, у нас есть решение по обновлению пользователей из Excel - можем выложить

Дмитрий Васильев,

Отключите обязательность поля email: Вкладка Администрирование - Настройки - Главный модуль - Вкладка Авторизация - E-mail является обязательным полем

Vsevolod Kaloshin,

Тут такая ситуация, что права администратора дают полный доступ к информации на портале. И в принципе так на любой системе.

Можно, конечно исхитрится и отключить функционал авторизации под чужим пользователем и спрятать доступ к таблицам базы (надо отметить, что он и сейчас спрятан, доступ к ним неявный). Но никто не запретит админу закачать php файл через который он может авторизоваться под другим пользователем и сделать какой угодно запрос к базе данных.

И,  в целом, такая ситуация во всех системах.

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

Антон Янчук, напишите нам - http://www.mcart.ru/support/ попробуем помочь

Антон Янчук, а в каком у вас? Что-то нестадартное?

Владимир Сахно,

У нас есть альтернативное решение по визуализации структуры компании: http://marketplace.1c-bitrix.ru/solutions/mcart.companystructure/

Антон Янчук, попробуйте удалить пользователя на портале и запустить импорт еще раз. Он с фото будет создан на портале?

Внесу наши 5 копеек.

Мы сделали оптическое распознавание отсканированных документов на базе библиотеки Tesseract

Пример работы: http://www.mcart.ru/portfolio/2089/,  в маркетплейсе

 

Александр Шиховцев, нет, но если вы озадачите нашу поддержку - они помогут

Денис Клoкoв, по нашему опыту - календарь является слабым местом в портале.

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

Удалять события лучше через api, потому как структура хранения событий разнесена по 2 таблицы (если я правильно помню) - это таблица хранения событий и таблица с правами на действия с событиями в календаре

При этом, удаляя через api - убедитесь, что событие физически удаляется, по умолчанию оно остается в таблице и просто помечается как удаленное.

При общении с разработчиками, мы услышали такой тезис: "портал не предназначен на такое количество событий". На вопрос о лимитах событий - ответа мы не получили.

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