bugfix when favourite_tag unlock to set visibility #94
Conversation
|
ものすごーく細かい、というか実用上はあまり遭遇しないであろうケースで非常に申し訳ないのですが、
というケースと
というケースで、いずれもin_reply_toが残ったまま公開範囲がpublicになってしまいます。 いずれのケースもより狭いほうに合わせられる or 戻るというのが最も違和感のない動作ではないかと思います。 iconsの中にタグロックしたものだけでなくreplyで初期設定されている公開範囲も含めておくことが出来れば、上記の動作が得られるのかな…と思いますが、いかかでしょうか。 |
|
replyや、手動で公開レベルを変更した後でタグ設定を行った場合、
仕様に変更致しました。 お手数ですが、ご確認をお願い致します。 |
There was a problem hiding this comment.
確認したところ、privacyがpublicである状態から、公開範囲がunlistedに設定されたFavouriteTagをロック、解除しても公開範囲がdefault_privacyのpublicに戻りませんでした。
reducerの138行目を参照したところ、privacyがnullとなるのは初期状態のみですので、次状態のprivacyがdefault_privacyとなることがないため、このような動作となっているようです。
これをもし「ロックされているFavouriteTagが無ければprivacyをdefault_privacyに戻すという動作」に修正した場合、
- default_privacyはpublicである
- unlistedなtootに対する返信ボタンをクリックしてprivacyがunlistedに設定される
- privateなタグをロックし、解除する
- unlistedなtootに対するin_reply_toが残っているにも関わらずprivacyがpublicになってしまう
というケースが考えられます。
これらのprivacyの設定に関する動作の混乱は、privacyの範囲比較が138行目と142行目、更にその前のcomponents/favourite_tags.jsのcomponentWillUpdateと複数個所に分散してしまっていて全体像が把握しづらいのが原因のような気がします。
components/favourite_tags.jsのcomponentWillUpdateは問題なく動作しているようですのでそのままにするとしても、reducerのほうについては
- reply先のprivacyを保持しておくreply_privacyを新設
- privacyPreferenceを任意個比較できるように改修
map.set('privacy', privacyPreference(tag_privacy, reply_privacy, default_privacy))
とするのがコードの変更量はともかく実装としてはシンプルのような気がしてきたのですが、いかがでしょうか。
あとはreply_privacyをCOMPOSE_REPLY_CANCELやCOMPOSE_SUBMIT_SUCCESSの際に忘れずにクリアすれば大丈夫のような気がします。
|
対応が遅くなって申し訳ありませんでした。 ミスしてたところを修正しました。 |
v1.6系になって、
setDefaultTag実行後にclearAllが実行されなくなったようで、タグ解除時に公開設定が戻らなくなっていましたので修正しました( mastodon#4511 の影響？)。
また、#71 のシングルモードでの返信時の公開範囲設定も問題ないはずです。
fixed #87