Vadim Dumbravanu (Все сообщения пользователя)

Код

$arUsers = Bitrix\Main\UserGroupTable::getList(     array(         'order' => array('USER_ID' => 'DESC'),         'select' => array(             'USER_ID',             'USER_DATE_REGISTER' => 'USER.DATE_REGISTER',             'USER_ACTIVE' => 'USER.ACTIVE',             'USER_EMAIL' => 'USER.EMAIL',             'USER_WORK_PHONE' => 'USER.WORK_PHONE',             'USER_WORK_COMPANY' => 'USER.WORK_COMPANY',             'USER_NAME' => 'USER.NAME'         ),         'filter' => array(             'USER.ACTIVE' => 'N',             'GROUP_ID' => 7         ),         'count_total' => true,     ) ); echo $arUsers->getCount();

Будет сделано два запроса, первый для определения количества.

Попробуйте \Bitrix\Main\UserTable::getList(), там более предсказуемое поведение фильтра.

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

Для подобных случаев добавлен третий параметр в ф-ю Update. Нужно установить его в false:

Код
public function Update($ID, $arFields, $authActions = true)

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

Можно использовать штатный валидатор \Bitrix\Main\ORM\Fields\Validators\UniqueValidator:

Код
new Fields\StringField("PHONE_NUMBER", array(    'validation' => function() {         return array(             new Fields\Validators\UniqueValidator(Loc::getMessage("user_phone_auth_err_duplicte")),       );    } )),

На поле желательно иметь (уникальный) индекс, чтобы проверка проходила быстрее.

Насколько я помню, компонент highloadblock.list - это простой пример использования, возможно есть смысл сделать на его основе собственный полнофункциональный компонент.

Возможно, поможет этот материал: http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2741

У вас довольно старая версия. Просто удалите строку bitrix/modules/form/classes/mysql/form_cformresult.php:303 с запросом "SET SQL_BIG_TABLES=1".

Цитата
Илья Матвеев написал: Но хотелось, чтобы причину все таки озвучили.

Обновили PHP на контроллере CDN до 5.6, он стал требовать валидные SSL-сертификаты для соединений с внешними ресурсами. Обновили сертификаты, где нужно.

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

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

xcache.size обозначает память под прекомпилятор скриптов php. xcache.var_size - память под кеш переменных. Кеш в БУС использует именно кеш переменных.

Цитата
xcache.var_size  =            8M

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

1) Это называется "защищенное скачивание", нужно писать скрипт на php, который отдаст файл только после проверки прав доступа. Желательно при этом, чтобы файлы были за пределами корневой папки веб-сервера, либо в настройках веб-сервера запрещать доступ на определенные пути. В поставке продукта такого нет.

2) В модуле проактивной защиты есть настройка "Защита от фреймов", которая запрещает браузеру грузить ваш сайт в <iframe> на чужом домене (в том числе в гугл-переводчике и т.п.).

3),4) Как уже сказали выше, это довольно бесполезные и неудобные для легальных пользователей практики.

Я могу предположить, почему нет селектора по имени класса. Это медленно, у нас есть термин "массажировать DOM". Мы стараемся не использовать медленные методы и другим не советуем.

Это агент, который проверяет систему и выводит сообщение админу, если найдены ошибки. В описании обновления было: "Агент для проверки настроек продукта работает теперь и в БУС."

Возможно, у них общий кеш. В .settings.php в ключе cache нужно добавить атрибут sid с разными значениями.

Есть одна техническая деталь, которая, возможно, поможет. Фактическое смещение пользователя записывается  в поле b_user.TIME_ZONE_OFFSET при авторизации пользователя. Мы это поле используем, когда нужно посчитать время не для текущего пользователя, например. Можете попробовать использовать поле для калькуляции времени в мобильном приложении.

А почему не хотите довериться автоопределению смещения? Если мобильное приложение на нашей платформе, то оно точно так же кук устанавливает.

Подробнее в этой статье: http://dev.1c-bitrix.ru/community/blogs/vad/time-zones-in-version-11.php

Принцип очень простой. Все даты хранятся в локальном времени сервера. Ввод и вывод принимается в локальном времени пользователя. Смещение для пользователя определяется в порядке (только один вариант):

1) по настройке профиля пользователя;
2) автоматически по js, если включено;
3) по глобальной настройке смещения сервера.

Пример: сервер стоит в поясе Москвы, пользователь в Калининграде, включено автоопределение. В форме пользователь вводит "10.09.2015 10:30" и сохраняет. Мы считаем, что это его локальное время. В БД сохраняется в поясе сервера: "10.09.2015 11:30". Теперь тот же пользователь идет в список элементов, где мы выводим ему запись. Читаем из БД  "10.09.2015 11:30", знаем, что у него смещение минус час, показываем ему "10.09.2015 10:30". Пользователь видит ровно то, что вводил на форме. Если на этот список посмотрит пользователь из Лондона, то он увидит в своем локальном времени: "10.09.2015 9:30".

Калькуляцией смещения занимается класс CTimeZone. Преобразование времени происходит на уровне записи в БД/выборки из БД в ф-ях CDatabase::DateToCharFunction() и CDatabase::CharToDateFunction().

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

В профиле пользователя есть выбор зоны. Кроме того, есть механизм автоопределения из js браузера. Включается в настройках ядра.

Штатная ф-я CUser::CheckFields() проверяет логин на уникальность в том числе и для Update(). Но у вас остается возможность изменить поля в событии OnBeforeUserUpdate уже после проверки. В этом случае вы сами должны обеспечить целостность своих данных.

Если в форме авторизации написано "...Доступ к файлу ... запрещен", то у пользователя, под которым вы авторизовались, нет доступа к панели управления. Перейдите в публичный раздел, если там есть признаки авторизованного пользователя, вы их увидите.