Расширить существующий контроллер?

Разработка
1

Всем привет, надеюсь, я публикую это в нужном месте. Я пытаюсь разработать плагин для своего нового сайта на Discourse.

Я сделал форк репозитория с примером здесь, настроил работу Plugin Outlet, но затем уперся в стену и начал чувствовать себя довольно потерянным и растерянным. Я только недавно начал разбираться в MVC PHP-фреймворках, таких как Laravel, но с JS-фреймворками я абсолютно новичок. Раньше я никогда не работал с Ruby, Rails или Ember.

Проблема

Мой сайт предназначен для сообщества ТСЖ (HOA). Моя задача — собирать и сохранять несколько дополнительных полей данных для каждого пользователя:

  • legal_name (строка)
  • is_owner (булево)
  • is_resident (булево)
  • building (строка) — номер здания
  • unit (строка) — номер квартиры
  • … и несколько других внутренних переменных, например, подтвердил ли модератор пользователя.

Я хочу сделать эти поля обязательными при регистрации пользователей. Это означает, что нужно изменить форму регистрации. Я подключился к outlet create-account-after-password и вывел дополнительные поля, но, очевидно, это не делает их функциональными.

Думаю, мне нужно расширить контроллер в app/assets/javascripts/discourse/app/controllers/create-account.js, не только чтобы перехватывать новые значения формы при отправке, но и для чего-то столь (казалось бы) простого, как использование названия сайта this.siteSettings.title в поле перевода client.en.yml! (Сейчас заголовки дополнительных полей в моей форме регистрации выглядят так: “Каково ваше отношение к [отсутствующее значение %{title}]?”, что, очевидно, недопустимо.)

Чем больше я пытался найти ответы, тем больше вопросов возникало, и они становились всё сложнее. Разные руководства, которые я пытался следовать, apparently были написаны для разных версий Discourse. В репозитории с примером плагина есть вещи, которые я не понимаю. В чем разница между клиентским маршрутом и серверным маршрутом? В чем разница между плагином и модулем? Я совсем потерялся.

Если кто-то сможет помочь, я буду очень благодарен. Заранее спасибо.

2

Думаю, вы можете сделать это с помощью Creating and configuring custom user fields

3

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

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

4

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

6

Это можно сделать без программирования с помощью Creating and configuring custom user fields

8

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

Что ж, моя конечная цель/видение заключалось в следующем:

1. Многоуровневая модерация

Предоставить владельцам каждой единицы в сообществе права модератора ТОЛЬКО в отношении жителей их единицы.

Учитывая, что в нашем сообществе почти 200 единиц, использование функции групп для этого казалось нереалистичным. См. также пункт 3 ниже, с которым группы также вступили бы в конфликт.

2. UX регистрации

Идеальный UX, по моему мнению, также должен был бы динамически реагировать на выбор пользователя в поле «здание» в выпадающем меню «единица» на форме регистрации, предлагая только те единицы, которые находятся в выбранном здании. (Я собирался найти способ разбора файла конфигурации JSON для этого при инициализации Discourse.)

3. Настройки конфиденциальности полей

Я хотел предоставить каждому пользователю возможность выбора: скрывать ли номер своего здания и/или единицы от других пользователей, не входящих в их единицу.

Мое впечатление таково, что основная функция пользовательских полей предлагает эту опцию только для каждого поля (а не для каждого пользователя) и кроме того, только администраторам, а не самим пользователям.

4. Стилизация

Это было бы скорее вишенкой на торте, но вместо отображения чего-то вроде «Владелец: да» я хотел бы предоставить системе специальные знания об этих полях, чтобы стилизовать их по-другому в сводках пользователей. Например, добавить SVG-иконку документа о праве собственности и галочку, если модератор подтвердил их статус (или иконку дома для жителей). Что-то в этом роде.

Так что, да…

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

Многие жители моего сообщества — пожилые люди с минимальными знаниями в области компьютеров или без них. У меня есть серьезные опасения, что некоторые из них не захотят внедрять и использовать мой сайт на Discourse просто потому, что он новый и не Facebook, не говоря уже о реальных проблемах использования, таких как конфиденциальность адреса или некорректный ввод номеров зданий/единиц.

9

Группы отлично подойдут для этой цели, и вы можете легко создать 200 групп.
Вам нужно будет только вручную или программно сопоставить поле с группой. Однако, возможно, вы также захотите, чтобы пользователи предоставляли какое-то «подтверждение» после регистрации.
Вы можете сделать это вручную, написать код самостоятельно или использовать плагин кастомного мастера Pavilion для этой цели.

Это верно, но вы можете настроить так, чтобы пользователи, желающие сделать это публичным, отображали это поле в другом месте, то есть иметь «частное» поле здания и «публичное» поле здания.

10

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

Это можно реализовать в компоненте темы, поэтому плагин для этого не обязателен, но если вы делаете плагин, вы также можете включить в него изменения фронтенда. Разработка плагинов Discourse — Часть 1: Создание базового плагина. Также стоит поискать плагины, добавляющие аналогичный функционал. Существует репозиторий Discourse под названием all-the-plugins, который поможет найти примеры.

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

Именно для этого предназначены компоненты темы. Быстрый справочник разработчика тем может стать отличной отправной точкой.

11

Мне кажется, TS не собирался форкать Discourse??

12

Похоже, что репозиторий, на который он дал ссылку, является форком, а не плагином.

13

image

Форк discourse-plugin-skeleton кажется мне хорошим началом для написания плагина…

14

Согласен! Не знаю, что мне показалось! Не понимаю, как я не заметил, что это форк. :person_shrugging:

Мне казалось, я искал plugin.rb…

15

Ничего страшного, я узнал кое-что из этого разговора :grin:

16

Спасибо @RGJ за разъяснение! :sweat_smile: Да, я точно никогда не стал бы форкать сам Discourse только ради этого.

17

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

Включает ли это их добавление в модальную форму «Создать аккаунт» и возможность сделать их обязательными? Можете ли вы указать на какие-либо примеры или руководства по выполнению этого?

Я уже прочитал полное руководство, на которое вы ссылались: «Разработка плагинов для Discourse». Именно с него я начал. В итоге единственная реальная функциональность, которую оно показывает, как расширять, — это создание новой страницы администратора с фиолетовым щупальцем. У меня уже работает страница администратора для моего плагина, но я даже не уверен, что она мне понадобится. Она не связана с текущими проблемами, с которыми я столкнулся, поэтому их пример не очень полезен в моём случае.

18

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

На самом деле потребуется от 400 до 600 групп, чтобы охватить все комбинации (владелец, жилец или аффилированное лицо для каждой единицы). Но как это будет работать? Могут ли все 200 групп отображаться у пользователей одинаково, чтобы вместо «Владелец 187» или чего-то подобного просто было написано «Владелец»?

Это скорее детальный вопрос, но раскрывается ли какой-либо внутренний идентификатор группы конечным пользователям, например, в URL? Если пользователь установил номер своей единицы как приватный, сможет ли кто-то узнать его, сравнив идентификатор группы с данными других пользователей?

Мне кажется, что у меня могут быть лучшие результаты, если я создам всего 3 группы (владелец, жилец и аффилированное лицо — или просто 2: владелец и жилец). Возможно, я смогу назначать эти группы соответствующим образом, как вы и сказали, а затем блокировать определённые действия, если пользователь пытается модерировать жителя не той единицы?

Думаю, если блокировка такого действия абсолютно невозможна, то да, мне придётся создать 600 групп… и просто надеяться, что у пользователей не возникнет хитрых идей «взломать» систему и выложить личные данные кого-либо.

19

Погодите. Что? То есть если я арендатор и что-то пишу на форуме, мой домовладелец может изменить мои слова? Темы принадлежат только одной категории, так что у вас получатся разговоры только между владельцем и арендатором.

Это не имеет смысла. И на самом деле нет простого способа настроить права доступа на уровне темы.

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

20

Я ничего не говорил о правах доступа на уровне тем.

Возможно, слово «модератор» выбрано неверно? Не знаю. (Раньше я никогда не использовал Discourse.)

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

Моя цель — максимально привязать доступ к форуму к юридической цепочке полномочий, касающейся каждого конкретного объекта недвижимости. Ни один подтверждённый владелец, который законно владеет недвижимостью здесь, не должен быть забанен, но если он опубликует пост, нарушающий правила, этот пост может быть удалён сотрудниками. Однако, если он продаст недвижимость, его статус «владельца» будет немедленно аннулирован, что может привести к исключению с сайта (если только он не выберет статус «партнёра» и не получит одобрение нового владельца недвижимости).

В нашем сообществе между единицами в одном здании нет никакой связи, кроме физической пристыковки. Всё. Группировка людей по зданиям — это в основном косметическое решение для удобства интерфейса; назначение полномочий над целыми зданиями здесь не имело бы смысла.

21

Я нашёл это: Add a custom per-user setting in a plugin

В комментариях один пользователь написал, что «запатчил контроллер». У него есть файл .js.es6 в assets/javascripts/discourse/initializers/, который ссылается на метод api.modifyClass() …

Хмммммм :thinking: Возможно, я на верном пути.

22

Отлично! Вот оно что!

Я бы посоветовал вам сначала лучше разобраться в системе Discourse, прежде чем принимать окончательное решение о том, что именно вы хотите делать.

Думаю, будет проще, если доступ на сайт будут одобрять несколько человек, а не каждый владелец отдельной квартиры. Если решение принимают владельцы, что произойдёт, когда кто-то продаст свою квартиру? Кто тогда будет принимать решения? А как насчёт владельца, которому всё равно, станет ли его арендатор участником форума? Я считаю, что доверить это управляющему комплексом — гораздо более разумное решение, и, скорее всего, для этого даже не потребуется плагин.