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

[YuriBtr 58]

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

 

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

[celsoft 6 082]

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

[YuriBtr 58]

7 часов назад, celsoft сказал:

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

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

 

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

 

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

 

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

Изменено 23 августа 2018 пользователем YuriBtr

[celsoft 6 082]

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

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

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

 

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

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

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

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

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

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

[alex32 942]

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

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

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

 

[Gameer 310]

@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;
}

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

Изменено 24 августа 2018 пользователем Gameer

[alex32 942]

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

[YuriBtr 58]

4 часа назад, celsoft сказал:

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

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

 

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

[Gameer 310]

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

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

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

[webair 178]

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

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

[alex32 942]

3 часа назад, Gameer сказал:

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

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

[Gameer 310]

1 час назад, alex32 сказал:

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

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

[alex32 942]

1 час назад, Gameer сказал:

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

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

[celsoft 6 082]

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

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

 

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

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

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