Bug(バグ) #3544
完了「全メンバーをコミュニティ参加させる」リンクによって招待済みで登録していないメンバが登録できなくなる場合がある
0%
説明
概要¶
「全メンバーをコミュニティ参加させる」リンクによって招待済みかつ登録していないメンバが登録できなくなる場合がある.
また,そのようなメンバに対してさらに招待を送ると招待時にホワイトアウトする場合がある.
詳しくは下記のような複数のバグにより上記現象が発生する.
- 「全メンバーをコミュニティ参加させる」リンクによって招待済みで登録していない(is_active=0)のメンバが参加してしまう
- 新規登録完了処理時に初期コミュニティにすでに参加している場合に投げられた例外が拾われずに登録処理の途中で停止する
- 招待時にプロフィールが登録されており is_active=0 となるようなメンバのメールアドレスを指定した場合に同じメンバで pc_address と pc_address_pre に同じメールアドレスが登録される場合があり,このような状態になった時にそのメールアドレスを含んだ招待を行おうとするとホワイトアウトする.
これら問題について,どのメールアドレスあるいはメンバに問題が発生しているかが Web インタフェース上では判別不能のためユーザがこの問題の認識および解決を行うことは困難である.
発生バージョン¶
OpenPNE 3.8.9
OpenPNE 3.6.13
原因¶
複数の不具合を含んでいるが問題発生の起点となるものは『「全メンバーをコミュニティ参加させる」リンクによって招待済みで登録していない(is_active=0)のメンバが参加してしまう』という問題のためその原因について記述する.
#927 修正時に Doctrine のオブジェクトによるクエリ発行から SQL によるクエリ発行に変更された際に opActivateBehavor を考慮したクエリが発行されなくなった. master ではその後 メソッド抽出からの修正が行われているため本問題は発生しない.
修正案¶
- #927 の修正のように is_active について考慮したクエリを発行するように修正する
- また すでに is_active=0 のメンバがコミュニティに参加してしまっている場合を考慮して新規登録完了時の already join の例外を適切に処理して登録を完了できるようにする
- すでに複数のメンバあるいは同メンバ無いで pc_address および pc_address_pre (または mobile のそれ)について複数で同じメールアドレスが登録されているメンバについてはそのデータを削除する
kaoru n さんが約10年前に更新
- 担当者 を kaoru n にセット
この不具合が発生している場合、apacheのエラーログに「This member has already joined this community.」と出力されます。
masterにて修正されているコミットは下記の2つです。
https://redmine.openpne.jp/projects/op3/repository/revisions/f015591f24dc30871fab2907f47cfd7e879598a7
https://redmine.openpne.jp/projects/op3/repository/revisions/54c1b47624a3f4bede413df6a9180db4f8fc6711
問題のあるレコードを削除する¶
下記(1)のSQL実行により、不整合となってしまったデータが存在するか確認できます。
下記(2)のSQL実行により、データを削除する前に再度招待が必要なメールアドレスの一覧が取得できます。
下記(3)、(4)のSQL実行により、不整合となってしまったデータを削除することができます。
(1)is_active が 0 であるにもかかわらずコミュニティメンバになっているメンバidとコミュニティidの取得
SELECT member.id as member_id, member.is_active, community_member.community_id as community_id FROM member LEFT JOIN community_member ON member.id = community_member.member_id where member.is_active = 0;
(2)一旦削除するため、再招待が必要なメールアドレスの修得
SELECT member_id as member_id, value as value, member_config.name as name, member.created_at as created_at FROM member_config LEFT JOIN member ON member_config.member_id = member.id WHERE member_config.name IN ('pc_address', 'pc_address_pre', 'mobile_address', 'mobile_address_pre') AND is_active = 0 AND member.id IN (select member_id from member_profile) ORDER BY member_id;
(3)is_active が 0 であるがコミュニティに参加してしまっているレコードの削除
DELETE community_member FROM community_member LEFT JOIN member ON community_member.member_id = member.id WHERE member.is_active = 0;
(4)プロフィール登録が済んだところでエラーが発生してしまい,中途半端に登録完了できていないメンバの削除
DELETE FROM member WHERE is_active = 0 AND id IN (SELECT member_id FROM member_profile);
isao sano さんが約8年前に更新
- 関連している Backport(バックポート) #4051: 「全メンバーをコミュニティ参加させる」リンクによって招待済みで登録していないメンバが登録できなくなる場合がある を追加
isao sano さんが約8年前に更新
- 関連している Backport(バックポート) #4052: 「全メンバーをコミュニティ参加させる」リンクによって招待済みで登録していないメンバが登録できなくなる場合がある を追加
Shinichi Urabe さんが約8年前に更新
- ステータス を Pending Review(レビュー待ち) から Rejected(差し戻し) に変更
opAuthMailAddressPlugin を使っている場合など、基本的には opAuthAdapter::activate()
が呼ばれ、 Member::setIsActive(true) ≒ 1
が DB に保存されることが多いですが、 opActivateListener
において、アクティブなユーザは member.is_active = 1 OR member.is_active IS NULL
のケースが定義されています。
opActivateListener
の定義から member.is_active IS NULL
をアクティブと見なす認証プラグインが存在するケースもないとは言えないかと思いますので、member.is_active = 1 OR member.is_active IS NULL
を判定条件とする必要があるように感じます。
Shinichi Urabe さんがほぼ8年前に更新
- ステータス を Pending Review(レビュー待ち) から Pending Testing(テスト待ち) に変更
- 進捗率 を 50 から 70 に変更