Unable to grant admin rights due to error

Bug
1

Hi!

When trying to grant admin rights to a user (any user actually) I only get the following error message (after clicking the confirmation link):

image
image695Ă—163 10.1 KB

I checked the logs and found the following messages:

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

At about the same time I also get a message about MaxMind not working properly, not sure whether this has anything to do with it (didn’t find any related settings in the admin interface):

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

How do I debug this further?

Thanks,
Hannes

2

You get that error when you click the “Grant Admin” button?

3

No, clicking the “Grant Admin” button works.

The full process is like this:

  1. I click the “Grant Admin” button, application presents me with a modal “We’ve sent you an email to verify the new administrator. Please open it and follow the instructions.”
  2. I click the confirmation link in the email (“Confirm Administrator Account”) which brings me to a confirmation page.
  3. On the confirmation page I click the button “Grant Admin Access”, which then produces the error page (see screenshot in my original post) and also the error messages in the log.

I also just noticed the following message further up in the log (prefixed with the number 46 - does this mean that it has been repeated 46 times?):

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

4

this feels is a very interesting edge case. Assuming this is self hosted, what does this return?

./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]]

Discourse is very particular about these ids, staff must be 2, admins must be 1. If somehow you have a different group with that name there could be trouble. I would also ensure no user is called admins

5

It looks like this (there are many more groups, but they were clearly created by us and didn’t have any resemblance with the system groups, so I didn’t include them below):

=> [["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]]

I notice that there is no group staff, only Staff - if staff always has id 3 then I guess this indicates that somebody removed it and created a new group (id 42).

Is it enough to create staff again or how can I solve this?

6

Yeah I think renaming your staff group will be enough to sort the issue

1 Like
7

The UI doesn’t allow me to do it:

image
image975Ă—112 5.94 KB

Do I need to do this directly in the DB?

8

Is it possible to rename the group using the command line or how can I resolve this situation?

9

Try directly from the DB then, it should be safe

2 Likes
10

Yes, this did the trick! The group existed, but somebody had renamed it - since this basically breaks core functionality I am wondering whether renaming of system groups should be disallowed in the UI.

For the records, in case somebody ends up in a similar situation:

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

Yeah it absolutely should be a state you can not get in to

2 Likes