غير قادر على منح حقوق المسؤول بسبب خطأ

خلل
1

مرحباً!

عند محاولة منح حقوق المسؤول لمستخدم (أي مستخدم في الواقع) ، أحصل فقط على رسالة الخطأ التالية (بعد النقر فوق رابط التأكيد):

صورة
صورة695×163 10.1 KB

لقد تحققت من السجلات ووجدت الرسائل التالية:

ActiveRecord::RecordInvalid (Validation failed: Name has already been taken) app/models/group.rb:607:in 'refresh_automatic_group!' app/models/group.rb:666:in 'block in refresh_automatic_groups!' app/m

Failed to handle exception in exception app middleware : ActiveRecord::RecordInvalid : Validation failed: Name has already been taken

في نفس الوقت تقريبًا ، تلقيت أيضًا رسالة تفيد بأن MaxMind لا يعمل بشكل صحيح ، ولست متأكدًا مما إذا كان هذا له علاقة بالمشكلة (لم أجد أي إعدادات ذات صلة في واجهة المسؤول):

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-City.mmdb) could not be found: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-City.mmdb

كيف يمكنني تصحيح هذا الأمر بشكل أكبر؟

شكراً،
هانيس

2

هل تحصل على هذا الخطأ عند النقر فوق الزر “منح المسؤول”؟

3

لا، النقر على زر “Grant Admin” يعمل.

العملية الكاملة كالتالي:

  1. أنقر على زر “Grant Admin”، يعرض التطبيق نافذة منبثقة “لقد أرسلنا لك بريدًا إلكترونيًا للتحقق من المسؤول الجديد. يرجى فتحه واتباع التعليمات.”
  2. أنقر على رابط التأكيد في البريد الإلكتروني (“Confirm Administrator Account”) الذي ينقلني إلى صفحة تأكيد.
  3. في صفحة التأكيد، أنقر على زر “Grant Admin Access”، والذي ينتج بعد ذلك صفحة الخطأ (انظر لقطة الشاشة في مشاركتي الأصلية) وكذلك رسائل الخطأ في السجل.

لاحظت أيضًا الرسالة التالية في أعلى السجل (مسبوقة بالرقم 46 - هل هذا يعني أنها تكررت 46 مرة؟):

Error ensuring consistency for Group: Validation failed: Name has already been taken

4

تبدو هذه حالة خاصة جدًا ومثيرة للاهتمام. بافتراض أن هذا مستضاف ذاتيًا، ماذا سيعيد هذا؟

./launcher enter app
rails c
Group.pluck(:name, :id)

=> [["everyone", 0],
 ["moderators", 2],
 ["admins", 1],
 ["staff", 3],
 ["trust_level_0", 10],
 ["trust_level_1", 11],
 ["trust_level_2", 12],
 ["trust_level_3", 13],
 ["trust_level_4", 14]]

دسكورس دقيق جدًا بشأن هذه المعرفات، يجب أن يكون الموظفون 2، ويجب أن يكون المسؤولون 1. إذا كان لديك بأي شكل من الأشكال مجموعة مختلفة بهذا الاسم، فقد تكون هناك مشكلة. سأحرص أيضًا على عدم وجود مستخدم يسمى admins.

5

يبدو الأمر كالتالي (هناك المزيد من المجموعات، ولكن من الواضح أننا أنشأناها ولم يكن لها أي تشابه مع مجموعات النظام، لذلك لم أدرجها أدناه):

=> [["everyone", 0],
 ["moderators", 2],
 ["admins", 1],
 ["trust_level_0", 10]
 ["trust_level_1", 11],
 ["trust_level_2", 12],
 ["trust_level_3", 13],
 ["trust_level_4", 14],
 ["Staff", 42]]

ألاحظ أنه لا توجد مجموعة staff، فقط Staff - إذا كانت staff دائمًا تحمل المعرف 3، فأعتقد أن هذا يشير إلى أن شخصًا ما أزالها وأنشأ مجموعة جديدة (المعرف 42).

هل يكفي إنشاء staff مرة أخرى أو كيف يمكنني حل هذه المشكلة؟

6

نعم أعتقد أن إعادة تسمية مجموعة الموظفين الخاصة بك ستكون كافية لحل المشكلة

إعجاب واحد (1)
7

لا تسمح لي واجهة المستخدم بذلك:

image
image975×112 5.94 KB

هل أحتاج إلى القيام بذلك مباشرة في قاعدة البيانات؟

8

هل يمكن إعادة تسمية المجموعة باستخدام سطر الأوامر أو كيف يمكنني حل هذا الموقف؟

9

حاول مباشرة من قاعدة البيانات إذًا، يجب أن يكون آمنًا

إعجابَين (2)
10

نعم، لقد نجحت هذه الطريقة! كانت المجموعة موجودة، ولكن قام شخص ما بإعادة تسميتها - نظرًا لأن هذا يكسر الوظائف الأساسية بشكل أساسي، فإنني أتساءل عما إذا كان يجب منع إعادة تسمية المجموعات النظامية في واجهة المستخدم.

للسجلات، في حال انتهى الأمر بشخص ما في موقف مماثل:

docker exec -it app /bin/bash
su - postgres
psql -d discourse
discourse=# update groups set name='staff' where id=3;
\q
5 إعجابات
11

نعم، يجب أن تكون بالتأكيد حالة لا يمكنك الدخول إليها

3 إعجابات