| Цитата |
|---|
| Дмитрий Петров написал: Хм. А он потом возвращает его? Может, пытаться менять какой-то атрибут... Мне нужна именно проверка на существование. |
|
Разработчикам |
Дмитрий (Все сообщения пользователя)
Доступ к почтовому пользователю по API
Доступ к почтовому пользователю по API
Импорт заказов из 1С - возможен ли импорт кастомных свойств заказов?, Проблема - невозможно записать/обновить свойства заказа из 1С
|
Александр Янцен,спасибо! Увы, вопрос уже давно не актуален: функционал реализовал самостоятельно в итоге.
|
|
|
|
|
Импорт заказов из 1С - возможен ли импорт кастомных свойств заказов?, Проблема - невозможно записать/обновить свойства заказа из 1С
|
Здравствуйте!
Есть набор кастомных свойств заказа, которыми должен проходить полный обмен с 1С. Настройка профилей произведена, свойства выгружаются в узлы "ЗначенияРеквизитов", но обратно на сайт не попадают - ни для новых заказов, созданных в 1С, ни для старых, пришедших с сайта. Основной вопрос - вообще возможно ли это сделать в стандартной конфигурации? |
|
|
|
|
Отсутствие валидации свойств инфоблока, Обсуждение причин отсутствия валидации свойств инфоблока
|
Александр Гусев, это все очевидно, модуль, обработчики - все запилено. Но раздражения от того, что функционал мягко говоря кривит, это не снимает.
Второе - возможно, v2 и стоит ближе рассмотреть, да, спасибо вам и Андрею Николаеву за пинок легкий. |
|
|
|
|
Отсутствие валидации свойств инфоблока, Обсуждение причин отсутствия валидации свойств инфоблока
|
Спасибо за понимание!)
И все же, нахожу весьма странным, что ИБ1 не производит валидацию на уровне PHP. Понятное дело, что в БД все значения будут храниться как строка и это никоим образом не мешает логике "Коль указан тип число, будь добр ввести число". Соответственно, сейчас приходится писать собственный обработчик, казалось бы, стандартного функционала. Особенно странным выглядит то, что тип "Число" в принципе лишен смысла, нет никаких причин оставлять его числом кроме битриксовых шаблонов, где от типа свойства МОЖЕТ зависеть внешний вид поля. Спасибо за ответ, по крайней мере я буду больше уверен в том, что проблема именно в отсутствии функционала как такового, а не документации по нему. Хотя ещё интересно было бы услышать мнение приближенных к Битрикс, быть может, есть этому разумное объяснение. |
|
|
|
|
Отсутствие валидации свойств инфоблока, Обсуждение причин отсутствия валидации свойств инфоблока
|
Здравствуйте!
Очень интересная ситуация складывается со свойствами инфоблока: казалось бы, у нас есть 6 базовых типов свойств, причем для некоторых вполне очевидна необходимость проверки данных на соответствие типу: в поле с числом не должно быть возможно вписать строку, а привязка к элементу ни в коем случае не должна привязываться к заведомо несуществующему элементу. Что же имеем по факту? И в поле типа "Число", и в поле типа "Привязка к элементу" (требуется ввести числовой ID элемента) можно вписать абсолютно любой текст и движок вполне спокойно и добропорядочно его сохранит, даже не тронув некорректные данные. Таким образом, в числе и в привязке у нас может храниться краткий пересказ "Войны и Мира" и даже админка не скажет нам ни слова против, не говоря уж об API.   Итак, центральный вопрос, почему же отсутствует элементарная серверная валидация таких очевидных типов свойств? Понятное дело, что можно реализовать все на событиях добавления/обновления инфоблока или даже переопределить базовые свойства и уже в собственном коде реализовать проверку данных на соответствие типу, но почему УС не предоставляет этот функционал из коробки? |
|
|
|
|
Установка прав доступа на конкретных пользователей, Разграничение прав доступа конкретным пользователям, делегирование прав
Установка прав доступа на конкретных пользователей, Разграничение прав доступа конкретным пользователям, делегирование прав
|
Здравствуйте!
Если я правильно понял из разграничение прав доступа возможно лишь на уровне групп пользователей. Однако, на данный момент мне необходимо реализовать функционал, по котором конкретный пользователь сможет разрешать править свои данные другим пользователям. Первая мысль (она же неправильная) - для каждого пользователя создать свою уникальную группу и уникальный инфоблок и так распределить доступы. Соответственно, если необходимо эти же доступы передать иному лицу - просто добавляем его в эту самую уникальную группу. Но решение является крайне страшным костылем, влекущим создание тысяч мусорных групп и тысяч мусорных инфоблоков. Вторая мысль - существует расширенное распределение прав, при котором права на просмотр/редактирование элемента инфоблока можно делегировать лишь на автора этого элемента. Тогда возникают три вопроса:
|
|
|
|
|
Отдельная таблица для результатов веб-формы
