أهلاً بالجميع، آمل أن أكون أنشر هذا في المكان الصحيح. أحاول تطوير إضافة لموقع Discourse الجديد الخاص بي.
لقد قمت بعمل fork لمستودع الأمثلة هنا، وحصلت على Plugin Outlet يعمل، ثم اصطدمت بحائط وبدأت أشعر بالضياع والارتباك. بدأت مؤخرًا في فهم أطر عمل MVC PHP مثل Laravel، لكنني جديد جدًا على أطر عمل JS. لم ألمس Ruby أو Rails أو Ember من قبل.
المشكلة
موقعي مخصص لمجتمع HOA. ما أحاول القيام به هو جمع وحفظ بعض الحقول الإضافية للبيانات لكل مستخدم:
legal_name (سلسلة نصية)
is_owner (قيمة منطقية)
is_resident (قيمة منطقية)
building (سلسلة نصية) - تمثل رقم المبنى الخاص بهم
unit (سلسلة نصية) - تمثل رقم الوحدة الخاص بهم
… وبعض المتغيرات الداخلية الأخرى، مثل ما إذا كان المشرف قد أكدهم.
أريد جعل هذه الحقول إلزامية عند تسجيل المستخدم. هذا يعني تعديل نموذج تسجيل المستخدم. لقد ربطت بـ create-account-after-password outlet وحصلت على بعض الحقول الإضافية للعرض، ولكن من الواضح أن هذا لا يجعلها وظيفية.
أعتقد أنني بحاجة إلى توسيع المتحكم في app/assets/javascripts/discourse/app/controllers/create-account.js، ليس فقط لالتقاط قيم النموذج الجديدة عند إرسالها ولكن حتى لشيء (يبدو) أساسي مثل استخدام اسم الموقع this.siteSettings.title في حقل ترجمة client.en.yml! (في الوقت الحالي، الحقول الإضافية في نموذج التسجيل الخاص بي تحمل عنوان “ما هي علاقتك بـ [قيمة %{title} مفقودة]؟” وهو أمر سيء بشكل واضح.)
كلما حاولت البحث عن إجابات، زادت أسئلتي وأصبحت أكبر. كانت الأدلة المختلفة التي حاولت اتباعها مكتوبة لإصدارات مختلفة من Discourse. يحتوي مستودع الأمثلة على أشياء لا أفهمها. ما الفرق بين مسار العميل ومسار الخادم؟ ما الفرق بين إضافة ووحدة؟ أنا ضائع جدًا.
إذا كان بإمكان أي شخص تقديم بعض المساعدة، سأكون ممتنًا جدًا. شكرًا مقدمًا.
\u003e ما الذي تريد فعله بهذه البيانات؟ لدي انطباع بأنك تريد تخزينها لوظيفة أخرى بدلاً من مجرد عرضها في مكان ما في المنتدى.\n\nحسنًا، كان أملي/رؤيتي النهائية هي:\n\n## 1. إشراف متدرج\n\nمنح مالكي كل وحدة في المجتمع صلاحيات إشراف على سكان وحدتهم فقط.\n\nمع الأخذ في الاعتبار أن هناك ما يقرب من 200 وحدة في مجتمعنا، لم يبدُ من الممكن استخدام ميزة المجموعات لتحقيق ذلك. انظر أيضًا #3 أدناه، والتي ستتعارض معها المجموعات أيضًا.\n\n## 2. تجربة مستخدم التسجيل\n\nستجعل تجربة المستخدم المثالية في ذهني أيضًا القائمة المنسدلة لـ “الوحدة” في نموذج التسجيل تتفاعل ديناميكيًا مع اختيار المستخدم في حقل “المبنى”، وذلك لتقديم الوحدات الموجودة في هذا المبنى فقط. (كنت سأكتشف طريقة لتحليل ملف تكوين JSON لهذا عند تهيئة Discourse).\n\n## 3. إعدادات خصوصية الحقول\n\nأردت أن أقدم لكل مستخدم خيار ما إذا كان يريد إخفاء رقم المبنى و/أو الوحدة الخاصة به عن المستخدمين الآخرين الذين ليسوا في وحدته.\n\nانطباعي هو أن ميزة الحقول المخصصة الأساسية تقدم هذا الخيار لكل حقل على حدة (وليس لكل مستخدم) وأيضًا للمسؤولين فقط، وليس للمستخدمين أنفسهم.\n\n## 4. تصميم أنيق\n\nسيكون هذا أشبه بـ “تزيين الكعكة”، ولكن بدلاً من عرضه كشيء مثل " المالك: نعم"، أردت أن أمنح النظام معرفة خاصة بهذه الحقول لتصميمها بشكل مختلف في ملخصات المستخدمين. مثل وضع أيقونة سند ملكية SVG، وعلامة اختيار إذا أكد المشرف حالتهم (أو أيقونة منزل للمقيمين). هذا النوع من الأشياء.\n\n## لذا، نعم…\n\nربما أكون انتقائيًا للغاية هنا، لكنني أشعر أنه بمجرد تجاوزي لمنحنى التعلم لتحقيق الوظائف الأساسية، فإن قائمة الأمنيات الصغيرة ستصبح تافهة تقريبًا.\n\nالعديد من المقيمين في مجتمعي هم كبار السن الذين لديهم معرفة قليلة أو معدومة بالكمبيوتر. لدي مخاوف جدية بشأن عدم رغبة بعض السكان في تبني واستخدام موقع Discourse الخاص بي لمجرد أنه جديد وليس فيسبوك، ناهيك عن مشاكل الاستخدام الحقيقية مثل خصوصية العنوان أو إدخال أرقام المباني/الوحدات غير المصادق عليها.
ستعمل المجموعات بشكل جيد لهذا الغرض، ويمكنك بسهولة الحصول على 200 مجموعة.
كل ما ستحتاج إلى القيام به هو تعيين الحقل يدويًا أو برمجيًا على مجموعة. ولكن قد ترغب أيضًا في أن يرسل الأشخاص نوعًا من “الإثبات” بعد التسجيل.
يمكنك القيام بذلك يدويًا، أو ترميز ذلك بنفسك، أو استخدام المكون الإضافي للمعالج المخصص من Pavilion للقيام بذلك.
هذا صحيح، ولكن يمكنك أن تجعل المستخدمين الذين يرغبون في عرضه علنًا يعرضون هذا الحقل في مكان آخر، أي أن يكون لديك حقل بناء “خاص” وحقل بناء “عام”.
إذا كنت بحاجة إلى إضافة ميزات، فأنت تريد إنشاء مكون إضافي (plugin) أو مكون سمة (theme component)، وليس استنساخ Discourse.
يمكنك القيام بذلك في مكون سمة، لذلك لا تحتاج إلى مكون إضافي لذلك، ولكن إذا كنت تقوم بإنشاء مكون إضافي، فيمكنك تضمين تغييرات الواجهة الأمامية في المكون الإضافي أيضًا. تطوير مكونات Discourse الإضافية - الجزء الأول - إنشاء مكون إضافي أساسي. البحث عن مكونات إضافية تضيف وظائف مماثلة هو أيضًا طريقة جيدة للمضي قدمًا. يوجد مستودع Discourse يسمى all-the-plugins يمكنك استخدامه للبحث عن أمثلة.
يبدو أن وجود إصدارات عامة وخاصة لتلك الحقول كما هو مقترح حل جيد، ولكن يمكنك أيضًا إضافة حقول المستخدم في مكون إضافي والتحكم في كيفية إضافة تلك الحقول إلى المُسلسِل (serializer) لعرضها، أو ما إذا كان سيتم إضافتها.
\u003e يمكنك أيضًا إضافة حقول المستخدم في مكون إضافي والتحكم في كيفية وما إذا كانت هذه الحقول تُضاف إلى المُسلسِل لعرضها.
هل يشمل ذلك إضافتها إلى نموذج “إنشاء حساب” الافتراضي، وجعلها مطلوبة؟ هل يمكنك توجيهي إلى أي أمثلة أو أدلة حول كيفية القيام بذلك؟
لقد قرأت بالفعل الدليل بأكمله الذي ربطته بـ “تطوير مكونات Discourse الإضافية”. هذا هو المكان الذي بدأت منه. في النهاية، الوظيفة الوحيدة الحقيقية التي يوضح كيفية توسيعها هي إنشاء صفحة مسؤول جديدة مع مجس برتقالي. لدي بالفعل صفحة مسؤول تعمل لمكوني الإضافي، لكنني لست متأكدًا حتى مما إذا كنت سأحتاج إليها. إنها غير مرتبطة بالمشاكل الحالية التي أواجهها، لذا فإن مثالهم ليس مفيدًا جدًا في حالتي.
ستعمل المجموعات بشكل جيد لهذا الغرض، ويمكنك بسهولة الحصول على 200 مجموعة
سيكون في الواقع ما بين 400 و 600 لتغطية جميع التباديل (مالك، مقيم، أو تابع لكل وحدة). ولكن كيف سيعمل ذلك؟ هل يمكن لـ 200 مجموعة أن تعرض جميعها بشكل متطابق للمستخدمين، بحيث تقول فقط “مالك” بدلاً من “مالك 187” أو شيء من هذا القبيل؟
هذا سؤال أكثر تفصيلاً، ولكن هل يتم الكشف عن معرف المجموعة الداخلي للمستخدمين النهائيين في أي مكان، على سبيل المثال، في عنوان URL؟ إذا قام المستخدم بتعيين رقم وحدته على أنه خاص، فهل يمكن لشخص ما معرفته عن طريق التحقق من معرف المجموعة مقابل مستخدمين آخرين؟
يبدو لي أنني قد أحصل على نتائج أفضل بإنشاء 3 مجموعات فقط (مالك، مقيم، وتابع - أو مجموعتين فقط: مالك ومقيم). ربما يمكنني تعيين تلك المجموعات حسب الاقتضاء كما قلت، ثم حظر إجراءات معينة إذا كان المستخدم يحاول الإشراف على مقيم في وحدة خاطئة؟
أعتقد أنه إذا كان حظر إجراء مثل هذا مستحيلاً تمامًا، فعندئذ سأكون عالقًا في إنشاء 600 مجموعة … وآمل فقط ألا يكون لدى أي مستخدمين أفكار ذكية “لاختراق” النظام وكشف معلومات أي شخص.
انتظر. ماذا؟ فإذا كنت مستأجرًا وقلت شيئًا في المنتدى، فهل يمكن لمالك العقار تغيير كلماتي؟ الوحدات مملوكة لفئة واحدة فقط، لذلك سيكون لديك محادثات بين المالك والمستأجر فقط.
هذا لا معنى له. ولا توجد طريقة سهلة حقًا لامتلاك أذونات على مستوى الوحدة.
أعتقد أنك سترغب في بعض المجموعات والفئات لكل مبنى، ولكن التحكم لكل وحدة لا معنى له.
ربما “مشرف” هي الكلمة الخاطئة؟ لا أعرف. (لم أستخدم Discourse من قبل حتى الآن.)
أنا أتحدث عن الموافقة على الوصول إلى المنتدى أو إزالته لكل مستخدم. لذا لا، لا يمكن للمالك تغيير كلماتك، لكنهم هم من لديهم السلطة لتأكيد تسجيلك كمقيم، وإذا أصبحت متصيدًا فيمكنهم إسكاتك أو حظرك. تتم إدارة المشاركات والمواضيع على حد سواء وفقًا لسياسة المحتوى، من قبل موظفي الموقع، وليس من قبل المالكين.
هدفي هو ربط الوصول إلى المنتدى قدر الإمكان بالسلسلة القانونية للسلطة على كل عقار بحد ذاته. لن يتم حظر أي مالك مؤكد يمتلك عقارًا هنا بشكل قانوني أبدًا، ولكن إذا قام بنشر مخالف لسياسة ما، يمكن للموظفين إزالة هذا المنشور. ومع ذلك، إذا باعوا العقار، فسيتم إلغاء وضع “المالك” الخاص بهم على الفور، مما قد يؤدي إلى إزالتهم من الموقع (ما لم يختاروا وضع “منتسب” ويتم الموافقة عليهم من قبل المالك الجديد للعقار).
في مجتمعنا، لا توجد علاقة بين وحدة وأخرى في نفس المبنى، باستثناء أنها متصلة جسديًا. هذا كل شيء. تجميع الأشخاص حسب المبنى هو قرار تجميلي لتجربة المستخدم؛ تعيين سلطات على المباني بأكملها لن يكون منطقيًا هنا.
في التعليقات، قال أحد المستخدمين إنه “قام بتصحيح وحدة تحكم”. لديه ملف .js.es6 في assets/javascripts/discourse/initializers/ يشير إلى طريقة تسمى api.modifyClass() …
أنصحك بأن تتعرف على المنتدى بشكل أفضل قبل أن تقرر ما تريد فعله بالضبط.
أعتقد أنه سيكون من الأسهل إذا وافقت مجموعة صغيرة من الأشخاص على انضمام الآخرين إلى الموقع بدلاً من أن يتحكم كل مالك لوحدة في الوصول إلى الموقع. إذا كان الملاك هم من يقررون، فماذا يحدث عندما يبيع شخص ما وحدته؟ من سيقرر حينها؟ ماذا عن المالك الذي لا يهتم بما إذا كان المستأجر الخاص به يمكنه أن يكون عضوًا في المنتدى؟ أعتقد أن ترك الأمر لمدير المجمع سيكون منطقيًا أكثر ومن المحتمل ألا يتطلب إضافة.
نعم، بالتأكيد لم أكن لأقوم بعمل fork لـ Discourse نفسه لهذا الغرض.
ربما أنا على وشك اكتشاف شيء ما.