Там два контура проверки доступа, в этом компоненте.
Первый - это код:
| Код |
|---|
// check whether current user can have access to add/edit elements
if ($arParams["ID"] == 0)
{
$bAllowAccess = count(array_intersect($arGroups, $arParams["GROUPS"])) > 0 || $USER->IsAdmin();
}
else
{
// rights for editing current element will be in element get filter
$bAllowAccess = $USER->GetID() > 0;
}
|
А дальше 2 раза в коде компонента встречается проверка условия:
| Код |
|---|
if ($bAllowAccess)
{
...
}
|
А второй контур при фильтрации элементов инфоблока:
| Код |
|---|
// check type of user association to iblock elements and add user association to filter
if ($arParams["ELEMENT_ASSOC"] == "PROPERTY_ID" && strlen($arParams["ELEMENT_ASSOC_PROPERTY"]) && is_array($arResult["PROPERTY_LIST_FULL"][$arParams["ELEMENT_ASSOC_PROPERTY"]]))
{
if ($USER->GetID())
$arFilter["PROPERTY_".$arParams["ELEMENT_ASSOC_PROPERTY"]] = $USER->GetID();
else
$arFilter["ID"] = -1;
}
elseif ($USER->GetID())
{
$arFilter["CREATED_BY"] = $USER->GetID();
}
// additional bugcheck. situation can be found when property ELEMENT_ASSOC_PROPERTY does not exists and user is not registered
else
{
$arFilter["ID"] = -1;
}
|
В нём как раз и решается проблема фильтрации через замену $USER->GetID() на null
Оба контура проверки надо отключить. Ну и учитывать, что это модификация ядра Битрикс, при каждом обновлении этот код будет слетать. Я бы кастомизированный компонент создал iblock.element.add, чтобы не корёжить ядро.
