# 無効なメールアドレスを持つユーザーの降格を支援するリクエスト
**URL:** https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990
**Category:** Support
**Created:** [2022 年 6 月 4 日午前 3:11 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990 "2022-06-04T03:11:50Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022 年 6 月 4 日午前 3:11 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990/1 "2022-06-04T03:11:50Z")
歴史的な理由から、Google+インポーターはユーザーをTL1でインポートし、Google+難民に有利なスタートを切れるようにしました。彼らは[`.invalid`のメールアドレスでインポートされ、](https://meta.discourse.org/t/bounty-google-private-communities-export-screenscraper-importer/108029/14?u=mcdanlj)ログインしてGoogle ID経由で既存のユーザーレコードに接続される際に修正されます。
しかし、私の`trust_level_1`グループには、まだコンテンツをフォローしていない何千人ものユーザーが滞留しており、数年後に（時々そうするように）現れた場合、Basicユーザーとして参加する特別な理由はありません。彼らはNewユーザーであるべきです。ブートストラップはとうに過ぎました。ログインしたことがないユーザーをTL0に降格させ、彼らが現れて確認するまで、通常の昇格プロセスに依存させたいと考えています。
Railsコンソールでこれを試しました。
```ruby
User.where(trust_level: 1) do |u|
u.change_trust_level!(TrustLevel[0]) if !Email.is_valid?(u.primary_email&.email)
u.save!
end
```
CPUをフルに消費して数分かかりましたが、何も起こりませんでした。（他にも`if !u.primary_email.is_valid?`や`if !Email.is_valid?(u.primary_email)`のようなバリエーションを試しましたが、本当の問題は年に一度しかRubyに触れないことだとわかっています…）他の人には明白な何かを見落としているに違いありません。誰かヒントをいただけると幸いです！
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022 年 6 月 4 日午前 3:52 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990/2 "2022-06-04T03:52:49Z")
`.each` が明らかに不足していました
```plaintext
User.where(trust_level: 1).each do |u|
u.change_trust_level!(TrustLevel[0]) if !Email.is_valid?(u.primary_email&.email)
u.save!
end
```
これにより、実行中に大量のIOが発生してサイトがダウンし、変更も行われませんでした。そのため、まだ何か間違っており、ライブシステムでこれを試すことを続けることに少し心配しています。☺
`is_valid?` が意味することではないことがわかりました。そのため、現在はリテラル文字列を検索しており、メールアドレスを印刷してテストしました。また、`change_trust_level` は既にユーザーを保存するため、2回保存する必要がないこともわかりました。
```plaintext
User.where(trust_level: 1).each do |u|
if u.primary_email&.email.end_with?(".invalid")
u.change_trust_level!(TrustLevel[0])
end
end
```
しかし、`trust_level_1` のユーザー数は依然として変化しないため、まだ何か重要なことを見落としています。
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [2022 年 6 月 4 日午前 9:43 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990/3 "2022-06-04T09:43:17Z")
この場合、一括管理タスクを使用できますか？
> [@tshenry](#):
>
> ## すべてのユーザーを自動信頼レベルにする [↥](#heading--0)
>
> * * *
>
> 新規ユーザーまたは招待されたユーザーのデフォルトの信頼レベルを、期待どおりに機能しない値（TL4など）に設定したとします。次に、ユーザーが現在の統計情報に基づいて自動的に信頼レベルになるように変更したいとします。次のコマンドは、[Understanding Discourse Trust Levels | Blog](https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/) に従って、すべてのユーザーが本来あるべき信頼レベルに設定されていることを保証します。 **注意** : 信頼レベルがロックされているユーザーは影響を受けません。
>
> すべてのユーザーが正しい信頼レベルに設定されていることを確認します。
>
> ```plaintext
> rails c
> User.all.find_each do |user|
> Promotion.recalculate(user)
> end
>
> ```
>
> 変更を反映するためにグループ統計を更新します。
>
> `Group.ensure_consistency!`
* * *
ただし、2番目のコードをテストしたところ、テストユーザー（メール：test\_thirteen@here.invalid、TL1からTL0になりました）で機能しました。
```plaintext
User.where(trust_level: 1).each do |u|
if u.primary_email&.email.end_with?(".invalid")
u.change_trust_level!(TrustLevel[0])
end
end
```
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2022 年 6 月 4 日午前 11:28 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990/4 "2022-06-04T11:28:33Z")
UserEmailモデルから始め、メールアドレスに「invalid」が含まれるものを検索し、それらをループ処理しますが、これは携帯電話では正確に把握できません。
「invalid」が含まれるアドレスが本当に無効であれば、保存できなかったはずです。
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022 年 6 月 4 日午前 11:49 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990/5 "2022-06-04T11:49:58Z")
ありがとうございます！
既存のコミュニティメンバーの間で、以前からよく知られていた一部のユーザーを手動で昇格させたため、一括再計算では私の望む結果にはなりませんでした。（検索中にそのページを見つけました。）
前回は、実際に機能していました。私の問題は、`/g` グループの概要ページを見て、それを更新し、`trust_level_1` グループのカウントが減少するのを待っていたことでした。実行中にカウントの変更が表示されなかったので、Control-C で停止しました。今朝、`trust_level_1` グループには、そのページに表示されるメンバーが数千人少なくなっていました。それで、そこでのカウントはキャッシュされていることに気づき、カードをクリックして `/g/trust_level_1` ページのカウントを見るべきだったと理解しました。
これで、そのページのカウントを修復するために `Group.ensure_consistency!` を実行すべきだったことがわかりました。
全体を、より簡潔で慣用的な表現で示します。
```plaintext
User.where(trust_level: 1).each do |u|
u.change_trust_level!(TrustLevel[0]) if u.primary_email&.email.end_with?(".invalid")
end
Group.ensure_consistency!
```
無効なメールアドレスしか持たないユーザーのうち、実際にサイトを利用し、TL1 の要件を満たしていた記録がいくつかあります。それがどのようにして起こったのかはわかりませんが、今のところ気になりません。私が本当に気にかけているのは、少数の例外を心配することなく、数千人の大部分を処理することです。もしこれが他の誰かに起こった場合、これは私にはうまくいきました。
```plaintext
User.where(trust_level: 1).each do |u|
begin
u.change_trust_level!(TrustLevel[0]) if u.primary_email&.email.end_with?(".invalid")
rescue
end
end
Group.ensure_consistency!
```
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [2022 年 6 月 4 日午前 11:56 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990/6 "2022-06-04T11:56:32Z")
> [@pfaffman](#):
>
> もし無効なアドレスが含まれているものが本当に無効であれば、保存することはできません。
背景は以下の通りです。
script/import\_scripts/friendsmegplus.rb
```plaintext
def import_google_user(id, name)
if !@emails[id].present?
google_user_info = UserAssociatedAccount.find_by(provider_name: 'google_oauth2', provider_u
nid: id.to_i)
if google_user_info.nil?
# システムに新しいGoogleユーザーを作成します。後でGoogle認証でログインした際に
# マージされることを期待します。
# G+データにはメールアドレスが含まれていないため、
# まだGoogle OAuth2に関連付けられていない別のアカウントを持っているかどうかはわかりません。
# ログインしなかった場合、アカウントには
# @gplus.invalid アドレスが関連付けられます。
email = "#{id}@gplus.invalid"
```
これは、`primary_email`のみを気にしており、`UserEmail`から始める必要がないことを意味します。私はその道を進み始めましたが、`primary_email`でなくなったものが、私が変更したくないものであれば、変更する必要がないことに気づきました。したがって、ここでは、唯一の（したがってプライマリの）メールアドレスが文字通り`.invalid`で終わるユーザーについて非常に具体的に述べており、それが私がやったことです。
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [2022 年 7 月 4 日午前 11:56 UTC](https://meta.discourse.org/t/requesting-help-demoting-users-with-invalid-email-addresses/228990/7 "2022-07-04T11:56:44Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.