Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нём некорректно. Вам необходимо обновить браузер или попробовать использовать другой.
Вот смотрите, я захожу в рег.ру, набираю домен в зоне ру и смотрю в Whois-сервисе:
Администратор домена Частное лицо «Private Person»
Регистратор RD-RU
Вам не кажется, что здесь какое-то противоречие? Персональные данные администратора всегда были приватными.
Далее, я воспользовалась их формой связи с администратором
и никаких согласий в ней не просят. Заявка в тех поддержку от гостя потребовала мое имя, мыло и никаких согласий не потребовала. Кто-кто, но они то должны знать, как правильно все сделать.
Я похоже нашёл решение.
За счёт одного плагина на тему повышение прав группы, если расширить функционал, то там есть возможность указать доп. поле на соглашение без каких-либо проблем.
Так вы же давали решение, как в форме регистрации добавить эти чебоксы. Или я что-то не понимаю.
По итогу в профиле новичка все галочки стоят, без них не зарегистрируется.
Нужно только еще один добавить - согласие на распространение.
У меня не стоят эти плагины. но такая галочка есть. Я включила повышение ради эксперимента и сегодня все мои пользователи заметили, что их сообщения уходят на премодерацию)) Отключила. Вопрос в том, что у них нет ПДн в логине)) поэтому эти действия нужно применять только к тем, у кого ФИО в логине и кидать их в отдельную группу... Если логин User999 или просто Вася, то пусть постят без галочки, а тех, у кого имя, с теми уже индивидуально решать...
Тут как раз всё правильно. И они остаются приватными. Объясню:
Для Whois использует обязательное скрытие данных физлиц. Это требует само законодательство о защиты ПД.
Для форм обратной связи использует законный интерес (п. 7.1 ст. 6 152-ФЗ) и исполнение запроса (п. 5 ч. 1 ст. 6 152-ФЗ), где достаточно уведомления, а не отдельного согласия.
Далее, я воспользовалась их формой связи с администратором
и никаких согласий в ней не просят. Заявка в тех поддержку от гостя потребовала мое имя, мыло и никаких согласий не потребовала. Кто-кто, но они то должны знать, как правильно все сделать.
Вы можете сделать так же для своей формы обратной связи, добавить текст под кнопкой, и она станет аналогичной. Но для регистрации и публичного отображения логина вам всё равно потребуются отдельные согласия, потому что это иные цели. Так что текущая схема с двумя чекбоксами является более правильной и безопасной, по крайне мере по закону. Юр.лица допускают упрощение, потому что они работают с договорами и публичной офертой. При регистрации опираются на это, потому у них чаще и допускаются 1 чекбокс (или просто кнопка) и всё. Мы как физ.лица этой привилегии лишены. Если я не прав, то поправьте. Я не юрист, чтобы разбираться, но серьёзно, с этой фигней невольно в этом сам начнёшь разбираться...
То, что вы им так написали, это ваше право))
Учитывая, что это не относится к 152-ФЗ, так как вы сами предоставили недостоверную информацию, то и рег.ру не несёт ответственности за это, но может запросить подтверждение, только и всего))
Да, только где сами чекбоксы и делать, про решение выше я писал, как обойти вопрос на согласие на распространение через права повышение групп, тут другое.
К тому же, как уточнил, нужно оставлять право пользователю редактировать галочку на согласие по распространению, по обработке нет.
Вам только стоит убрать пункт на политику конфиденциальности т.к. в правовой форме закона это неправильно и не является точной формулировкой, чекбокс с ним убыточен и не нужен, хоть и не требует, чтобы убрали. Но и переименовать его стоит на "Политика в отношении обработки персональных данных", тогда вопросов к вам не будет.
К сожалению эта форма служит для подтверждения политики конфиденциальности и правил форума и обозначения будут строго в БД. Рекомендуется о нём забыть и отключить в общих настройках полностью. В нашем случае она бесполезна, если конечно не переделать полностью наименование запросов на БД. Но если не хотите парится, то вырубите и используете доп. поля, где каждый имеет свою запись в БД. А уж как заставить подтверждать старых пользователей, вот тут надо подумать. Здесь я пока сам не знаю, но это только пока.
Возникает думаю закономерный вопрос, почему юр.лица допускаются 1 чекбокс или тупо кнопку при регистрации, а мы как физ. лица в этом ограничены, почему? Решил покопать вопрос и вот, что узнал... Отвечаю: Когда вы регистрируетесь на рег.ру или в Яндексе, вы заключаете с ними договор (публичную оферту) на оказание услуг. Обработка ваших данных (email, логин) для создания аккаунта и предоставления доступа - это исполнение договора.
Согласно п. 5 ч. 1 ст. 6 152-ФЗ, если обработка персональных данных необходима для заключения или исполнения договора, согласие субъекта не требуется. Именно поэтому они могут ограничиться коротким уведомлением под кнопкой. Они не берут согласие, они фиксируют факт заключения договора. Вот и вся разница с физ.лицом. Смиритесь.
Возникает вопрос, а почему мы, как владельцы форума должны делать 2 чекбокса?
Форум - это не просто договор на оказание услуги. У нас есть две цели, которые выходят за рамки простого предоставления доступа:
Регистрация и доступ к функционалу: Это можно считать исполнением договора (оферты). Здесь согласие формально не требуется, если вы обрабатываете только email и логин т.е. то, что не является публичным.
Публичное отображение логина: Это другая цель. Публикация вашего логина в профиле и сообщениях - это распространение персональных данных согласно ст. 10.1 152-ФЗ. Для этой цели требуется отдельное согласие, и его нельзя вшить в документ обработки ПД или в политику обработки ПД.
Именно из-за второй цели вам и нужен второй чекбокс на распространение. Первый чекбокс (на обработку) вы можете заменить на уведомление об оферте, если хотите упростить форму, но погоды вам не сделает, он обязателен для всех, а вот со 2 нужно смирится и доработать его работу.
К тому же 2 чекбокса тупо требование из-за самой платформы форума т.к. он требует эти условия. Будь у нас обычный сайт, как у рег.ру или яндекса, то такие условия можно было бы упростить. Если форум оформить на Юр.лицо, ИП, самозанятого, то требования по чекбоксам у всех одинаковы, разница будет только в документации по обработке ПД и политике ПД. Разница разве что ещё будет в том, что организации обычно делают форумы закрытыми и допускаются к регистрации только клиенты, то только в этом случае 2 чекбокс не нужен или вы сами не решили сделать его закрытым полностью от гостей, иного не дано. И как не странно посмотреть у других владельцев XF, мало кто правильно соблюдает эти нормы. То что их нет у других, не значит, что у них всё хорошо.
Мне тоже, честно, надоело. Я составила письмо пользователям такого содержания и опубликую на форуме, чтобы потом можно было сослаться.
Перемещу тех, кто до 31.12 не поставит галочку, в специальную группу, которой разрешу писать только в скрытых разделах. Тем, кто зарегается и не поставит галочку - премодерация. Всё.
У меня форум новый и маленький, чуть больше 2 тысяч сообщений, с сообщениями разберемся.
Тема: Важно: изменение правил отображения профилей и сообщений (152-ФЗ)
Здравствуйте, уважаемые участники форума!
Мы вынуждены обратиться к вам с важным изменением, которое касается каждого.
В чём ситуация
С недавнего времени российское законодательство (Федеральный закон № 152-ФЗ «О персональных данных») требует, чтобы для публичного отображения персональных данных (а к ним относятся логин, имя, аватар и любые сведения в профиле) у человека было отдельное добровольное согласие.
Раньше мы, как и многие форумы, работали по принципу «зарегистрировался - значит, согласен». Теперь это незаконно. Мы не можем показывать ваш логин, аватар или данные профиля в открытых разделах без вашего явного согласия.
Что это значит для вас
Мы не хотим удалять ваши сообщения или блокировать вас. Мы предлагаем выбор.
Вариант 1: Вы согласны на отображение
В настройках профиля в разделе "Информация" имеется отдельный пункт:
☐ Я согласен на публичный показ моего логина и данных профиля
Если вы её ставите:
Ваш логин, аватар и профиль отображаются как раньше.
Ваши сообщения остаются в открытых разделах.
Вы можете в любой момент отозвать это согласие, и мы скроем данные.
Вариант 2: Вы не согласны (или не ставите галочку)
Если вы не ставите галочку до 31.12.2026:
Ваши сообщения не удаляются.
Они будут перенесены в скрытый раздел, доступный только ограниченному кругу лиц.
В открытых разделах ваш логин и профиль отображаться не будут.
Вы сможете писать в закрытых разделах, где ваши данные не распространяются публично.
Почему мы это делаем
Мы не хотим рисковать блокировкой форума и штрафами. Но ещё больше мы не хотим потерять ваши сообщения и ваше участие. Поэтому мы идём на компромисс: кто не дал согласие - остаётся с нами, но в закрытом режиме.
Что нужно сделать
Зайдите в Настройки профиля.
Найдите пункт «Согласие на распространение персональных данных».
Поставьте галочку, если хотите, чтобы ваш профиль и сообщения оставались в открытом доступе.
Если не хотите - просто не ставьте. Но тогда после 31.12.2026 ваши сообщения автоматически будут перемещены в скрытый раздел.
Важно
Это не обязательная галочка. Мы не блокируем регистрацию и не удаляем аккаунты.
Вы можете дать, а потом отозвать согласие в любой момент. Тогда ваши данные снова будут скрыты, а сообщения перенесены в закрытый раздел.
Если у вас есть вопросы - пишите в эту тему или в личные сообщения администрации.
Мне удалось победить логику на "Распространение ПД"
Учитывая, что "Обработка ПД" прям требуется законом указать как чекбокс в нашем случае, то вот с необязательным "Распространение ПД" это работает иначе. К тому же чекбокс на нём обязывал указывать его необязательным, а вот с радиокнопками это работает иначе и это допускается, потому что есть выбор и он свободный, хоть и поле так же обязательно. Это прямой выход из ситуации.
Что нам это дает?
1) Мы никого не принуждаем и ничего не нарушаем.
2) Запись в БД, как на банальное условие Да/Нет.
3) Радиокнопки должны быть обязательны, если не ставить галку на это, то будет 3 выбор "не выбрано", а это нам не надо.
Спрашивается, а толку, если мы не можем контролировать их выбор? А вот фигу, можем и даже из коробки.
Для начала, нужно создать 2 группы пользователей /admin.php?user-groups/, например:
Без согласия на распространение
Согласие на распространение
Обе группы полная копия группы "Пользователи", с тем отличием, что в группе "Без согласия на распространение" отключено любое создание, загрузка и изменение на всё, что тока можно, можно только смотреть и качать, вы можете усложнить жизнь "антиПДшникам" на вашу фантазию.
Этот плагин поможет снять копию группы
У Вас недостаточно прав для просмотра ссылок.
Вход или Регистрация
Иконка на 2.3 с ним будет отсутствовать, но рядом найдёте слева от мусорки. Смело делаем копию и обзываем как удобно.
После как создали и настроили группы. Идём сюда admin.php?user-group-promotions/ и создаем 2 группы повышения групп, например как у меня:
Настройки такие:
1 вкладка выбираем группу, которая запрещает всё, что тока можно.
2 вкладка выбираем только "Группы пользователей" и ставим галку только на "Пользователь является участником одной из выбранных групп" и выбираем "Пользователи" вашу основную группу после регистрации любого пользователя.
3 вкладка указываем только на Распространение ПД - Я не даю согласие...
1 вкладка выбираем группу, которая разрешает всё, её можно назвать клоном "Пользователи" или можете создать как "Проверенные", как вам нравится и настраиваем по аналогии базовой или как-то иначе, тут неважно т.к. там они и останутся в результате (это касается тех, кто изначально указал против и после перешёл). Фигня в том, что повышение не убирает группу в пользу "Пользователи" никак, это работает только на доп.группы и потому важно разделение, иначе работать не будет условие. Если и возможно это решить иначе, то только через плагин какой-нибудь, а из коробки нет.
2 вкладка тоже самое, выбрать только Группы пользователей и поставить галку на Пользователи, что является участником одной из выбранных групп и это группа "Пользователи" или как они у вас там обзываются...
3 вкладка, выбираем только Распространение ПД - Я даю согласие... Мы создаем условие, где соглашаются, а где нет.
После всех настроек, запускайте планировщик и радуйтесь жизни. Логика работы проста, кто поставил кнопку против, тот попадает в группу с ограничением и если хотят вернутся, то в профиле просто поставят кнопку на согласия и спустя время планировщик их перекинет на другую группу, а с той уберет, а кто согласился, попадает в группу проверки с теми же правами, что и пользователи.
Не забудьте общий кэш обновить на повышение.
Идём сюда /admin.php?tools/rebuild и запускаем.
Правда этот принцип работает на новых пользователях, что уже успели столкнутся с этими полями, а вот чтобы старичков зацепить, ещё пока не придумал, как их обновить, но ничего и до них руки дойдут.
Может у кого будут какие предложения лучше? Я и так тут замучился с выяснением оптимального решения. Так же ещё не решил с вопросом скрытие логина для гостей, им ладно можно перекрыть просмотр профиля, а вот с логином надо подумать, как замаскировать вместе с аватаром, может у кого какие предложения? Не мне же одному работать.
И спросите, почему радиокнопки? Да потому что тупая логика XF не умеет работать с чекбоксами, даже поиск криво работает. Проблема в чём изначально с ними. При попытке повышать группы, алгоритм XF тупо не умеет определять разные чекбоксы, он их видит по принципу 1 и 0, если грубо выражаться, он даже вариативные не распознает, тем самым завязать на них условие скрипта не представляем возможным. И при поиске 1 чекбокса, даже если другой отключен, он найдёт всё равно их все т.к. они чекбоксы)) Я не знаю, почему такая идиотская логика, но она идиотская. Решение было задействовать радикопноки и обязательно, чтобы было условие на Да/Нет и только в этом случае повышение групп заработало как нужно и по поиску пользователей у кого какая радиокнопка стоит, он чётко фильтрирует где активна, а где нет. Вот и думайте теперь, сколько нового узнаешь в процессе.
Правда этот принцип работает на новых пользователях, что уже успели столкнутся с этими полями, а вот чтобы старичков зацепить, ещё пока не придумал, как их обновить, но ничего и до них руки дойдут.
Можно написать плагин, который будет обрубать доступ к форуму по аналогии как дополнение с подтверждением почты
Пример:
Делаем флаг для юзеров rules_agreed.
После определяем юзеров, которые уже согласились с этими правилами при регистрации, и обновляем им это поле rules_agreed в true.
Расширяем родную регистрацию и устанавливаем флаг в поле rules_agreed в true после успешной регистрации.
Для юзеров, которые уже существуют, контроллер будет перехватывать вызов и подсовывать нужную страницу, где будет форма, обязывающая человека согласиться с этими правилами. До тех пор, пока он не выполнит это действие, он ничего не сможет делать на форуме. После того как он соглашается, устанавливаем флаг rules_agreed в true, и больше он не видит эту страницу.
Как только правила обновляются или нужно снова подсунуть правила, делаем в настройках кнопку сброса отображения правил. Всем юзерам обнуляется поле rules_agreed, и они снова видят страницу с новой формой.
Ну и, конечно, форму делать не жёсткой, а взять за основу критерии дополнительных полей и самостоятельно отмечать, что именно должно быть в этой форме. В дальнейшем её будет легко расширять: достаточно будет добавить кастомное поле, а в настройках указать, нужно ли отображать это поле в форме. Таким образом, у нас будет гибкая форма.
-------
Тут только вопрос куда ведут ссылки с "Политикой в отношения обработки персональных данных" и "Согласием на распространение персональных данных"? На роутинг /help?
Тут только вопрос куда ведут ссылки с "Политикой в отношения обработки персональных данных" и "Согласием на распространение персональных данных"? На роутинг /help?
Они все создаются в /help. Но кто-то может им не пользоваться и могут создать форум страница, как тут на инфо идет на правила и форму обратной связи. Кому-то так удобно может быть, не стоит исключать.
Основная проблема в решении, что описал выше это:
1) невозможность правильного учета по чекбоксам и вынуждает использовать радиокнопки. И как не странно радиокнопки отлично подошли.
2) нет возможности скрыть отображение логина (установку аватара можно и в группе вырубить, как и смотреть профиль). Возможно через модификатор шаблона можно как-то зацепить условие по отображению... Распространение ПД без согласия запрещает любую публикацию аккаунта для гостей. Даже его отображение в списке пользователей.
3) нет возможности принудительно старым аккаунтам проставить подтверждение на чекбокс обработки ПД и конечно распространение ПД. Когда у тебя их десятки тысяч. Оно может и логично т.к. установка цепляется к дате установке, тут не знаю как решить.
Вроде ничего не пропустил?
P.S. С моей текущей настройкой по поиску пользователей, я чётко вижу, какие пользователи поставили согласия, а какие нет. С чекбоксом вы так не посмотрите, он выводит всех. Так что мой способ на новых пользователях работает отлично, ещё бы решить с отображением самого логина гостям и вопрос можно закрыть.
2) нет возможности скрыть отображение логина (установку аватара можно и в группе вырубить, как и смотреть профиль). Возможно через модификатор шаблона можно как-то зацепить условие по отображению... Распространение ПД без согласия запрещает любую публикацию аккаунта для гостей. Даже его отображение в списке пользователей.
Через модификацию Вы не предусмотрите отображение имени по всему форуму. Придётся во все шаблоны лезть, что нецелесообразно. Вопрос заключается в том, что Вы хотите видеть на выходе, если пользователь поставил не отображать своё имя - что тогда должно отображаться?
Проверил бегло сейчас замену имени на произвольное значение в коде XF\Templater, именно в функции fnUsernameLink — большую часть мест он заменяет. Раз в этой функции мы получаем $user, мы можем там проверить custom_fields и сверить то, что пользователь указал (хочет он, чтобы отображалось имя или нет).
Но нужно ещё модификации делать в профиле на замену xf:title, так как в профиле имя отображается в title. Также и в онлайне пользователей написано «скрыто», но если он просматривает, допустим, свой профиль, там пишется имя.
И это только то, что удалось бегло обнаружить. Нужно ещё выискивать места.
Хотел ещё уточнить насчёт мест, где есть поле ввода имени пользователя. Там мы будем получать его в поиске, если знаем настоящее имя - отсюда тоже получается несостыковка. И нужно ковырять еще куча других мест.
Так как подмену мы делаем лишь визуальную, пришла другая идея. А что, если человеку при нежелании отображать свой никнейм насильно устанавливать другой никнейм? Тогда по всему форуму будет отображаться установленный ник, например, «Участник #12», и не нужно никаких модификаций и танцев с бубнами.
Либо же дать возможность пользователю самому сменить «Имя пользователя» на желаемое.
3) нет возможности принудительно старым аккаунтам проставить подтверждение на чекбокс обработки ПД и конечно распространение ПД. Когда у тебя их десятки тысяч. Оно может и логично т.к. установка цепляется к дате установке, тут не знаю как решить.
Как уже писал выше, самый простой способ - это через плагин, который будет всё делать сам.
Уточню: как только он включается и у пользователя rules_agreed = false, пользователь уже не сможет пользоваться форумом до тех пор, пока не пройдёт форму с этими полями. После того как он всё отметил, согласился и сохранил, ему обновляется состояние, и он больше не видит эту страницу.
Насчёт тех юзеров, которые уже прошли регистрацию и подтвердили своё согласие, нужно обновить их отдельно, чтобы они повторно её не проходили. А в момент регистрации нужно добавить флаг на созданного юзера, так как он форму уже прошёл по логике в момент регистрации, чтобы он её также не увидел после успешной регистрации.
Если пользователь против "Распространение ПД", то его автоматом кидаем в группу, которая может только читать и качать, тем самым мы не ограничиваем доступ к форуму, но и писать ему нельзя давать т.к. нарушает ПД о публичности, но гости всё равно будут продолжать видеть его "Логин", можно ли его как-то скрыть или сделать выполнение скрипта, который бы подставлял вместо логина, допустим его ID профиля. Как вариант.
Хотел ещё уточнить насчёт мест, где есть поле ввода имени пользователя. Там мы будем получать его в поиске, если знаем настоящее имя - отсюда тоже получается несостыковка. И нужно ковырять еще куча других мест.
Речь именно про отображение имени логина. Неважно как его обзовут, хоть ФИО, нужно скрыть то, что вбивал пользователь в логине для "Гостей". Это основное условие. Всё остальное можно вырубить на уровне прав группы. И должно это условие выполняться при условии нахождении группы, что ограничивает права.
Так как подмену мы делаем лишь визуальную, пришла другая идея. А что, если человеку при нежелании отображать свой никнейм насильно устанавливать другой никнейм? Тогда по всему форуму будет отображаться установленный ник, например, «Участник #12», и не нужно никаких модификаций и танцев с бубнами.
Тоже неплохой вариант, вы просто подставляете рандомное системное наименование, которое никак не обозначает ПД, но можно ли по закону так, требует уточнение.
Единственное разумное решение, что я вижу для обновление старых учёток. Это задействовать базовую функцию обновления даты политики ПД, которая входит по умолчанию, но если мы её запускаем, то добавится 3 базовый чекбокс только на неё, она не мешает и можно оставить, но при обновлении даты, выводить будет всем принудительно окно на подтверждение политики, но чтобы все старички и новые смогли подтвердить чекбокс на него, то в ту же форму подтверждения нужно как-то засунуть доп. поля на подтверждения "Обработки ПД" и "Распространение ПД", только в этом случае мы ничего не нарушаем и никого не принуждаем. Потому что с пустыми полями мы обязаны прекратить предоставлять доступ, если кто отказывается ставить и принудить можем тока этим способом, в противном случае они не смогут использовать форум как надо. Вот как туда добавить, вопрос. Я говорю про /admin.php?force-agreement/privacy-policy
Может плагин и не нужен, просто нужно решить это условие. Оно самое разумное.
Уточню: как только он включается и у пользователя rules_agreed = false, пользователь уже не сможет пользоваться форумом до тех пор, пока не пройдёт форму с этими полями. После того как он всё отметил, согласился и сохранил, ему обновляется состояние, и он больше не видит эту страницу.
Это в идеале и подобное условие как раз выполняет это /admin.php?force-agreement/privacy-policy, потому что политику ПД мы можем в любой момент обновить и к ней же привязать выбор полей, если даже пусть и стоит у кого-то.
Насчёт тех юзеров, которые уже прошли регистрацию и подтвердили своё согласие, нужно обновить их отдельно, чтобы они повторно её не проходили. А в момент регистрации нужно добавить флаг на созданного юзера, так как он форму уже прошёл по логике в момент регистрации, чтобы он её также не увидел после успешной регистрации.
Тут согласен, повторно проходить новым это не нужно, разве что можно по шаблону согласится с политикой БД, что выше предложил, это не вызывает проблем и логично решает вопрос.
Предлагаю рассмотреть решение в этом направлении. Если проблематично, то нужно решать на уровне создания плагина.
Если пользователь против "Распространение ПД", то его автоматом кидаем в группу, которая может только читать и качать, тем самым мы не ограничиваем доступ к форуму, но и писать ему нельзя давать т.к. нарушает ПД о публичности, но гости всё равно будут продолжать видеть его "Логин", можно ли его как-то скрыть или сделать выполнение скрипта, который бы подставлял вместо логина, допустим его ID профиля. Как вариант.
Но опять же, это нужно собрать в дополнение и знать точный ID поля правила. Можете написать, какой ID у правила? Я скину пример дополнения. Тогда логика будет завязана на нём и сразу будет делать подмену имени практически во всех местах.
Исключением ещё, как писал выше, становится профиль юзера — заголовок страницы и прочие места, где есть поля ввода с именем пользователя.
Некоторые шаблоны модификации можно подвязать и поменять тоже без проблем. С аналогичным примером:
В общем, я бы сейчас старался решать проблему постепенно, а не пытаться зацепить всё сразу. Начал бы с малого, так как поле уже есть, и задача просто в скрытии имени в зависимости от настройки. А после уже перешёл бы к дальнейшим задачам, чтобы не распыляться.
О каком поле правила речь? Не понимаю. Доп. поля? Группа с ограничением? У всех свои кастомные ID.
К тому же, пользователь в группе "Не согласия" должен скрывать лишь отображаемое имя пользователя в списках активности и всё, в оценках и общении он не участвует.
Правда тут есть одна дилемма, если он вдруг решил отказаться от согласия по распространению ПД, то его автоматом кинет в ограниченную группу и вот тут встает огромная проблема. Где он возможно писал и оставлял реакции, это мы получается скрыть не сможем и запретить ему смену не можем т.к. нарушаем права, да и мы даже не заметим это... вот как это учесть? 0_о
Разумное решение сделать такое, что если пользователь при согласии писал посты, учавствовать в активности и всё такое и вдруг психанул и решил отказаться от распространение ПД, что с ним будет происходить? Переход в ограниченную группу и удаление всех его постов и реакций на всю его активность, приводя к изначальному состоянию т.е. полное обнуление и его чётко об этом уведомить. Не хочешь, попращайся со всей активностью. Жёстко, но зато для себя безопасно. Или (как мне преложили мысль):
В случае несогласия с распространением ПД, пользователь может подать просьбу об удалении/изменении учетной записи, в личном сообщении к одному из администраторов форума, либо в соответствующей теме на форуме. В этом случае будет заменен логин, e-mail, и пароль и сброшена сессионная запись на текущий момент. Всё содержимое, что было написано на форуме, от этой учетной записи, останется на форуме или будет удалено т.к. при удалении учётной записи, можно удалить и все сообщения по умолчанию.
Так же поставить условие, что пользователь может редактировать это поле только 1 раз и при его выборе, дальнейшее изменения может провести лишь администратор/модератор и это условие допускается. Мы не ограничиваем право, а следуем технической процедуре, что у нас так устроено. Тут без ручного вмешательства без запроса просто никак. Только для связи из ограниченной группы нужно разрешить возможность писать ЛС или в графе помощи указать куда ему написать на почту.
Возможно и автоматическое повышение группы теряет смысл? Я возможно усложняю вопрос и может есть более простое решение?
В общем, я бы сейчас старался решать проблему постепенно, а не пытаться зацепить всё сразу. Начал бы с малого, так как поле уже есть, и задача просто в скрытии имени в зависимости от настройки. А после уже перешёл бы к дальнейшим задачам, чтобы не распыляться.
Соглашусь, потому что скрыть видимоть вводимого логина для гостей это уже иная задача, которую решить из коробки не получится так просто.
Что говорят конкретно статьи по этому вопросу: ст. 10.1 152-ФЗ:
Часть 1: Требование об отдельном согласии
«Согласие на обработку персональных данных, разрешенных субъектом персональных данных для распространения, оформляется отдельно от иных согласий субъекта персональных данных на обработку его персональных данных»
«В случае, если из предоставленного субъектом персональных данных согласия на обработку персональных данных, разрешенных субъектом персональных данных для распространения, не следует, что субъект персональных данных согласился с распространением персональных данных, такие персональные данные обрабатываются оператором... без права распространения»
Часть 5: Запрет на передачу неограниченному кругу лиц
«...если в предоставленном субъектом персональных данных таком согласии не указаны категории и перечень персональных данных, для обработки которых субъект персональных данных устанавливает условия и запреты..., такие персональные данные обрабатываются оператором... без передачи (распространения, предоставления, доступа) и возможности осуществления иных действий с персональными данными неограниченному кругу лиц»
Что конкретно говорят РКН на тему того, что ник/логин является ПД:
Он может быть причастен к ПД, но с тем условием, что позволяет с его помощнью идентифицировать физ.лицо. Роскомнадзор в своих информационных письмах разъяснил, что логин и никнейм подпадают под определение "персональные данные", поскольку являются информацией, прямо или косвенно относящейся к определенному или определяемому физическому лицу. Если у никнейма есть уникальный владелец, и этот никнейм может быть использован для различения одного пользователя от другого, он уже подпадает под действие закона. Судебная практика и разъяснения специалистов указывают на то, что не любой никнейм автоматически является персональными данными. Если никнейм не позволяет установить сведения о владельце (например, это обезличенное прозвище, которое невозможно связать с конкретным человеком), то он может не подпадать под регулирование 152-ФЗ.
Как бы и входит и как бы нет, контекст в том, можно ли идентифицировать физ.лицо по нему, понимайте как хотите))
О каком поле правила речь? Не понимаю. Доп. поля? Группа с ограничением? У всех свои кастомные ID.
К тому же, пользователь в группе "Не согласия" должен скрывать лишь отображаемое имя пользователя в списках активности и всё, в оценках и общении он не учавствует. Правда тут есть одна дилемма, если он вдруг решил отказаться от согласия по распространению ПД, то его автоматом кинет в ограниченную группу и вот тут встает огромная проблема. Где он возможно писал и оставлял реакции, это мы получается скрыть не сможем и запретить ему смену не можем т.к. нарушаем права... вот как это учесть? 0_о Тут вероятно нужно учесть условие, чтобы резко все его посты и реакции, либо удалялись, либо скрывались, а вдруг он решит снова вернуть согласия? Вот как это учесть? Я вот не знаю))
Тогда обычным расширением и кастомным полем тут не обойтись. Лучше продумайте все нюансы, напишите подробное техническое задание и разместите тему в разделе Ищу исполнителя.
Тогда обычным расширением и кастомным полем тут не обойтись. Лучше продумайте все нюансы, напишите подробное техническое задание и разместите тему в разделе Ищу исполнителя.
ну, делать заказ не вижу пока оснований, тем более платный для разового решения. Нужно смотреть ещё способы как можно обойти вопрос.
К тому же пришёл к выводу, как вообще решить дилемму. Операции с правами повышение групп оказываются излишним. Делать радипокнопки тоже излишне. Позже распишу итоговый вариант, нашлась лазейка в статье. Уж слишком всё усложнил.
Я пришёл к выводу, что достаточно в окне регистрации сделать так и не парить себе мозги, можно просто не дать возможность зарегистрироваться и всё, мы же предоставляем право и имеем право ставить свои условия и это не нарушает ни их, не наши права. А то я изначально подстаривался под чужие права, но совсем забыл про свои.
На 2 чекбокс не смотрите, поправить надо границу поля. В остальном, такая формулировка будет допустима в рамках требований закона.
Обработка ПД:
Я даю согласие на обработку моих персональных данных
Я даю согласие на обработку моих персональных данных в соответствии с Политикой в отношении обработки персональных данных.
Распространение ПД:
Я даю согласие на распространение моих персональных данных
Я даю согласие на публичное отображение моего логина в профиле и сообщениях на форуме в соответствии с Согласием на распространение персональных данных.
Я принимаю Правила и условия и подтверждаю, что ознакомлен(а) с Политикой в отношении обработки персональных данных.
В связи с этим, повышение групп можете удалить, это оказалось излишним решением, но было занимательно проверить, благо не пригодилось.
В остальном, стоит сказать спасибо товарищам, что мне тыкнули на факт того, что слишком перемудрил и зашли со стороны, раз мы не можем создать нужные условия, то просто избавимся от них.
По факту мы принуждаем пользователя согласится на все чекбоксы и дает ссылки на документы, но при этом ставим это как своим условием для работы, ставя пользователя перед фактом, ты либо согласен, либо гуляй.
По факту, у нас должно быть 4 документа:
Правила и условия
Политика в отношении обработки персональных данных
Согласие на обработку персональных данных
Согласие на распространение персональных данных
Как их оформлять, выше уже писал.
Правда я ищу лазейку, как вообще избавиться от 2 чекбокса, так посмотреть, он вообще никак не вписывается в рамки форума.
Если пользователь отказывается от второго, он всё равно должен иметь возможность пользоваться сайтом, просто его данные не будут публично отображаться (или будут видны только зарегистрированным, в зависимости от настроек). Это подтверждается и разъяснениями Роскомнадзора, и судебной практикой.
То есть этот пункт больше не имеет значения, верно? Раз у нас нет технической возможности обеспечить ему "нераспространение", то по факту, сама регистрация уже является "распространением" и без его согласия невозможна, я правильно понимаю?
