SSO login and Jobs::EnsureDbConsistency both fail


(Felix Freiberger) #1

I have two sites having SSO enabled. After the latest update, both of them started failing SSO logons for moderators and admins (but not for normal users), with a localized error message that is similar to “name is already being used”:

          Verbose SSO log: Record was invalid: Group 3

          {:name=>"wird bereits verwendet"}

          

          nonce: ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
name: Felix Freiberger
username: felix.freiberger
email: ■■■■■■■■■■■■■■■■■■■■■■■■
avatar_url: 
avatar_force_update: 
require_activation: true
bio: 
external_id: 14
return_sso_url: 
admin: true
moderator: true
suppress_welcome_message: 
add_groups: 
remove_groups: 

More intriguingly, the logs also contain failures for Jobs::EnsureDbConsistency. They look like this:

Job exception: Validierung gescheitert: Name wird bereits verwendet
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/validations.rb:79:in `raise_record_invalid'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/validations.rb:43:in `save!'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/attribute_methods/dirty.rb:29:in `save!'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/transactions.rb:291:in `block in save!'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/transactions.rb:351:in `block in with_transaction_returning_status'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/transaction.rb:184:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/transactions.rb:220:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/transactions.rb:348:in `with_transaction_returning_status'
/var/www/discourse/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/transactions.rb:291:in `save!'
/var/www/discourse/app/models/group.rb:224:in `refresh_automatic_group!'
/var/www/discourse/app/models/group.rb:248:in `block in refresh_automatic_groups!'
/var/www/discourse/app/models/group.rb:247:in `each'
/var/www/discourse/app/models/group.rb:247:in `refresh_automatic_groups!'
/var/www/discourse/app/models/group.rb:234:in `ensure_consistency!'
/var/www/discourse/app/jobs/scheduled/ensure_db_consistency.rb:8:in `execute'
/var/www/discourse/app/jobs/base.rb:154:in `block (2 levels) in perform'

Since my SSO source hasn’t been updated and the internal check job fails, too, I think this is a Discourse bug.


Group 3 is the “staff” group (which is called “mitarbeiter” in German).


(Sam Saffron) #2

Something is messed up with the group names probably due to localizations.

Any ideas here @tgxworld


(Felix Freiberger) #3

I just found out that I also cannot revoke a user’s moderator permissions – this gives a 422 error, and the same error message is sent to /logs.

Upgrading to the latest beta didn’t change that.


(Alan Tan) #4

Can you check through the list of your group names and see if there is already a group with a similar name?

EDIT: Ooo nevermind I have a repro. Will fix.


(Alan Tan) #5

Ok in Meta’s case, the german translation for staff is “team” and we already have a group named team.


(Alan Tan) #6

There are two problems that I uncovered after the investigation.

First, the automatic group names are updated whenever the default locale of the forum is changed. However, the default automatic group names for each locale may be similar to the name of an existing group which is the cause of the Name has been taken error. The fix for this is pretty straight forward, if the localized name has already been taken, we simply fallback to the default name for that automatic group.

Next, a group name change means all the existing group mentions becomes outdated and we don’t have a warning discouraging users from changing group names like how we do for username change.

Instead of implementing the warning, I went ahead and implemented the feature to remap group mentions in all posts whenever a group name is changed.


Grant User to Mod/Admin issue
(Felix Freiberger) #7

Awesome, thanks @tgxworld! Indeed, in both instances with this problem, I do have a group called team. Thank you for fixing this :sunny:


Grant User to Mod/Admin issue
(Alan Tan) #9