Перейти к публикации

Очищаются дополнительные поля


Рекомендованные сообщения

Если в дополнительном поле (типа Список) в опции " Разрешить добавление для следующих групп:" указать группу Администратора, то при редактировании новости у Редакторов исчезает возможность редактировать это поле, и это то поведение, которое мне нужно. Но при изменении новости Редактором - выставленное ранее Администратором значение дополнительного поля попросту пропадает.

 

Нужно при сохранении новости проводить проверку - если у Редактора нет прав на изменение дополнительного поля, то просто не трогать его.

  • Нравится 1
  • Поддерживаю 2
  • Спасибо 1
Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, celsoft сказал:

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

Извините конечно, но вот вообще не очевидна данная "запланированная возможность".

 

ИМХО здесь проблема в логике работы скрипта. Если у Редактора нет доступа к Дополнительному полю ранее заполненному Администратором, то никакие действия Редактора не должны приводить к изменению/удалению дополнительного поля, тем более такое обычное действие как сохранение новости.

 

В том виде в котором существует функционал ограничения доступа к дополнительным полям, он (функционал) - бессмыслен. Представьте себе: я как Администратор, хочу к новостям делать свои примечания или замечания для журналистов, написавших эту новость. Они кинутся исправлять и затрут все мои замечания, хотя доступа к моему дополнительному полю у них как бы нет. Следовательно это баг, по моему мнению.

 

В общем я не могу даже представить сценария при котором данный функционал в нынешнем виде мог бы использоваться. Если я не прав - прошу написать, в каких use case это может использоваться. Спасибо.

Изменено пользователем YuriBtr
  • Нравится 1
  • Поддерживаю 2
  • Спасибо 1
Ссылка на сообщение
Поделиться на других сайтах
18 часов назад, YuriBtr сказал:

ИМХО здесь проблема в логике работы скрипта. Если у Редактора нет доступа к Дополнительному полю ранее заполненному Администратором, то никакие действия Редактора не должны приводить к изменению/удалению дополнительного поля, тем более такое обычное действие как сохранение новости.

Вы запретили этому пользователю публиковать что либо в это поле, новость, это единое целое, а не какие то поля отдельны от новости. Соответственно данные по этому полю, отправляемые вашим редактором обнуляются. То что поле не видно, не значит что его нет, это значит что для данного пользователя оно должно быть пустым, поэтому пустым оно и становится когда ваш редактор отправляет все данные для сохранения на сервер.

 

18 часов назад, YuriBtr сказал:

В том виде в котором существует функционал ограничения доступа к дополнительным полям, он (функционал) - бессмыслен. Представьте себе: я как Администратор, хочу к новостям делать свои примечания или замечания для журналистов, написавших эту новость. Они кинутся исправлять и затрут все мои замечания, хотя доступа к моему дополнительному полю у них как бы нет. Следовательно это баг, по моему мнению.

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

18 часов назад, YuriBtr сказал:

В общем я не могу даже представить сценария при котором данный функционал в нынешнем виде мог бы использоваться. Если я не прав - прошу написать, в каких use case это может использоваться. Спасибо.

Например когда кто то пишет новость, отправляет ее на сайт, но есть финальная часть которую администратор считает что должен написать сам, и не только администратор, но и пользователь из другой группы, например редактор. Доп. поля для публикаций придуманы и сделаны для более удобной публикации чего либо на сайте, на для внутренней переписки между пользователями внутри новости. Для внутренней переписки на сайте есть соответствующее меню, которое используется например для быстрого или полного редактирования, в котором есть пункт "Уведомление автору", где можно написать автору публикации что не так и что поправить.

Ссылка на сообщение
Поделиться на других сайтах
18 часов назад, YuriBtr сказал:

Если у Редактора нет доступа к Дополнительному полю ранее заполненному Администратором, то никакие действия Редактора не должны приводить к изменению/удалению дополнительного поля

Абсолютно поддерживаю. Налицо алогизм работы скрипта. Если нет доступа у редактора к этому полю, то с этим полем ничего не должно происходить. Заполнено оно или нет, ничего меняться не должно. А если оно очищается, значит, оно меняется, значит это противоречит логике. У него нет доступа, но он может, как минимум!!! очищать это поле. А раз он может очищать это поле, значит доступ есть. Ограниченный доступ, только на очищение, но он есть.

 

Ссылка на сообщение
Поделиться на других сайтах

@alex32

Открываем /engine/inc/xfields.php находим

case "init":

Ниже вставляем

$xf_perm = $db->super_query("SELECT xfields FROM " . PREFIX . "_post WHERE id='{$id}'");
$xf_perm = xfieldsdataload($xf_perm['xfields']);
$arrayXfGroup = [];

Чуть ниже найти

if( $value[19][0] AND !in_array( $member_id['user_group'], $value[19] ) ) {
    continue;
}

Заменить на

if( $value[19][0] AND !in_array( $member_id['user_group'], $value[19] ) ) {
    $arrayXfGroup[] = $value[0];
}

Далее найти

$postedxfields = $newpostedxfields;

Ниже вставить

foreach($arrayXfGroup as $xfPName) {
    if ($xf_perm[$xfPName]) {
        $postedxfields[$xfPName] = stripslashes($xf_perm[$xfPName]);
    }
}

в начале месяца написал фикс на dle-faq https://dle-faq.ru/faq/common/24751-kak-realizovat-chtoby-polzovatel-v-adminke-mog-redaktirovat-tolko-opredelennye-dop-polya.html

11 минут назад, alex32 сказал:

Абсолютно поддерживаю. Налицо алогизм работы скрипта. Если нет доступа у редактора к этому полю, то с этим полем ничего не должно происходить. Заполнено оно или нет, ничего меняться не должно. А если оно очищается, значит, оно меняется, значит это противоречит логике. У него нет доступа, но он может, как минимум!!! очищать это поле. А раз он может очищать это поле, значит доступ есть. Ограниченный доступ, только на очищение, но он есть.

 

Нет, лол. В dle через опу написана проверка. Если у человека нет доступа, то оно не попадает в обработку даже если заполнено другим выше стоящим по группе прав юзером. И просто напросто очищает все данные. А именно строка

if( $value[19][0] AND !in_array( $member_id['user_group'], $value[19] ) ) {
    continue;
}

Если прав нет, то пропускаем просто поле. Гениально.

Изменено пользователем Gameer
  • Нравится 1
  • Поддерживаю 1
  • Спасибо 1
Ссылка на сообщение
Поделиться на других сайтах

@Gameer я не имею отношения к вопросу ТС, и при нужде я и сам справлюсь. такие мелочи в дле я сам напишу. Непонятен подход разработчика к самому понятию "доступ". То есть, удалять он ничего не может, и изменять тоже? или удалять может, но добавлять нет? вы уж ответьте пожалуйста, а то непонятно. Оказывается, любой вася пупкин который ниже меня рангом, может просто взять и удалить мои правки. Я тут пишу, пишу, а потом чувак пришел, и все удалил? Хотя я ему разрешил только одну строчку отредактировать? Владимир, вы не правы.

  • Нравится 1
  • Поддерживаю 1
  • Спасибо 1
Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, celsoft сказал:

Например когда кто то пишет новость, отправляет ее на сайт, но есть финальная часть которую администратор считает что должен написать сам, и не только администратор, но и пользователь из другой группы, например редактор

Но это же именно то про что я и говорю. Администратор напишет финальную часть, а редактор после заметит опечатку в своем тексте - полезет править текст, и затрет финальную часть написанную Администратором. Неужели так тяжело понять про что я говорю?

 

У меня доп.поля не используются для переписки, я привел это как пример - чтобы было понятнее. Я на сайте использую Список (Да/Нет) например для вывода статьи в "горячем" блоке новостей через модули BlockPro или Custom. И мне не хочется чтобы каждый Редактор мог влиять на важные настройки.

Ссылка на сообщение
Поделиться на других сайтах
5 часов назад, alex32 сказал:

@Gameer я не имею отношения к вопросу ТС, и при нужде я и сам справлюсь. такие мелочи в дле я сам напишу. Непонятен подход разработчика к самому понятию "доступ". То есть, удалять он ничего не может, и изменять тоже? или удалять может, но добавлять нет? вы уж ответьте пожалуйста, а то непонятно. Оказывается, любой вася пупкин который ниже меня рангом, может просто взять и удалить мои правки. Я тут пишу, пишу, а потом чувак пришел, и все удалил? Хотя я ему разрешил только одну строчку отредактировать? Владимир, вы не правы.

Он не имеет права что либо делать, это сам скрипт делает, если у него нет прав на это поле то даже если оно было заполнено оно будет теперь пустым. Так как сам двиг его стрет.

Ссылка на сообщение
Поделиться на других сайтах

Хранились бы доп поля в БД раздельно, не было бы такого.

При существующей системе доп полей, только мерджить старый и новый массив доп полей с учетом прав пользователей. Странно, что сейчас тупо переписывается под чистую.

Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, Gameer сказал:

Он не имеет права что либо делать, это сам скрипт делает, если у него нет прав на это поле то даже если оно было заполнено оно будет теперь пустым. Так как сам двиг его стрет.

Так, блин, об том речь ТС и ведет. Что такое поведение неправильно.

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, alex32 сказал:

Так, блин, об том речь ТС и ведет. Что такое поведение неправильно.

А я о чем? И в чем я был не прав?????????????????????????

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Gameer сказал:

А я о чем? И в чем я был не прав?????????????????????????

Ну, допустим, в том, что приписал вопрос ТС мне)  остальном я с тобой солидарен в данном вопросе

Ссылка на сообщение
Поделиться на других сайтах
16 часов назад, YuriBtr сказал:

Но это же именно то про что я и говорю.

 

8 часов назад, alex32 сказал:

Так, блин, об том речь ТС и ведет. Что такое поведение неправильно.

Я принял ваши аргументы. Будем думать над этим. Вероятно исправлять поведение скрипта в данном вопросе.

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
×
  • Создать...