Sorry old post but why don’t you set up your theme as a repo in GitHub? Permission your design and UX team to have access to update the Theme in GitHub.
In Discourse you can now set Themes to auto update upon rebuild.
Your admins will now only need to rebuild to bring in any changes made by the Design and UX team and the latter will not need access to admin at all.
Just a short note:
When coding matters of access control, in general, these RBAC checks should be performed on the server side.
RBAC code in client-side Javascript can be manipulated by the client.
This means that when defining core RBAC permissions for staff, admins and moderators, this should be done (generally speaking) in Rails, not in Javascript.
OBTW, this is also how Discourse does RBAC now, using what Discourse calls “guardian”, a Ruby class called class Guardian, here:
If a developer is going to add RBAC checks in Javascript code by calling the Discourse API, keep in mind that this code can be compromised because code which runs in the browser can be manipulated.
My recommendation is to make sure all core RBAC code is performed on the server side and do not try to short cut this in client-side Javascript.
There is also trust level 4 and category moderators, in discourse 2.5 and beyond.
لدي حالة استخدام مشابهة، حيث أدير مجتمعًا غير ربحي صغيرًا، ويقوم أحد مستخدمينا بصيانة السمات والتصميم.
لا أرغب في منح أي شخص غيري وشريك الملكية الوصول إلى بيانات المستخدمين الخاصة (مثل عناوين البريد الإلكتروني وما إلى ذلك)، لكن لدي 4 مشرفين.
من أجل تمكين المصمم من العمل، اضطرت لإنشاء موقع نسخة بدون محتوى ليكون هو المدير فيه، ثم أقوم بنسخ السمات والمكونات يدويًا. ومع ذلك، فإن هذا غير مرغوب فيه لأن بعض التغييرات تتطلب محتوى لإثباتها.
لماذا لا تضيف بعض المحتوى إلى موقع المرحلة التجريبية / الاختبار؟ هذه هي التوصية النموذجية.
لذا، دع المطور يعمل على موقع الاختبار (staging) ويدفع السمات إلى GitHub. لكنك ستظل بحاجة إلى ترقيتها بنفسك. قد تتمكن من إجراء الترقية باستخدام واجهة برمجة التطبيقات (API) وجعل المطور قادرًا على تشغيلها بطريقة ما.
أعمل حاليًا على أداة قد تكون قادرة على المساعدة في ذلك.
لدينا هذه الحاجة بالضبط أيضًا، هل قام أي شخص بحلها بالصدفة؟
لا أعرف ما إذا كان هذا مفيدًا في هذا الموقف، ولكن إذا كنت تحتاج فقط إلى بعض المحتوى، فهناك مهمة populate في rake:
شكرًا لك، للأسف ليس مفيدًا حقًا في الوقت الحالي.
إذا كنت لا تثق في المصمم لرؤية بياناتك، فما هو الحل الذي تتخيله؟
هل يمكنك فقط تزويدهم بمفتاح API يسمح لهم باستخدام discourse_cli لدفع السمة إلى هناك، ثم تعطيله عندما ينتهون، ربما؟
لا يوجد سبب على الإطلاق لأن يتمكن المصمم من الوصول إلى 100 ألف مستخدم هههه. علاوة على ذلك، سيكون ذلك ضد قواعد اللائحة العامة لحماية البيانات. هل من الممكن إعطاء مفتاح سطر أوامر لتحديثات السمات فقط؟
عذراً! أعتقد أنك على حق.
الآن، على عكس وقت إنشاء هذا الموضوع (والذي يبدو أنه كان المكان الذي كان فيه عقلي عندما كتبت ردي)، لدينا بالفعل مفاتيح API مفصلة. لا ينبغي أن يكون من الصعب إضافة نطاق جديد فقط لإدارة السمات.
قد يكون من المفيد إنشاء موضوع جديد في Feature للمطالبة بنطاق مفتاح API لمطور السمات. تبدو هذه فكرة جيدة.
لا، ليس كذلك. قد يكون ضد قواعد ذلك الموقع، ولكن يمكن ويجب تغييرها.
سيكون من الجيد لو تمكن @AV_C من نشر مرجع لهذا المتطلب. على الرغم من أنني أقدر بشدة سبب رغبة العميل في تقييد الوصول إلى قاعدة المستخدمين وحتى الفئات الخاصة لأسباب متنوعة. يمكن للمسؤول الكامل الوصول إلى رسائل البريد الإلكتروني لتسجيل الأعضاء وقد تحتوي الفئات الخاصة على محتوى حساس آخر اعتمادًا على حالة استخدام العميل.
أعتقد أن @pfaffman لديه فكرة جيدة لضمان تغطية هذا النوع من الثغرات من خلال واجهة برمجة تطبيقات مسؤول مقيدة. بمجرد اكتمال عمل المصمم، يمكن إلغاء المفتاح حتى الحاجة إليه.
سيتناسب هذا أيضًا مع فكرة جاي بعدم إظهار المستخدم كمسؤول في صفحة “حول”.