-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
お知らせ機能の強化 #11328
Comments
規約違反した際の警告とか、必ず読んでほしいお知らせの場合、Misskey Webアクセス時にダイアログで強制的に表示するとかもしたいから、そうすると「通知の種類として『お知らせ』を新設する」はちょっと違うかも |
そのお知らせに対してユーザーが返信したりできるようにするかによっても実装が変わる |
返信までできるようにすると急激に実装コストが跳ね上がるから多分やらない |
そういうロールのユーザーからダイレクトノートが届くと目立つように表示されるみたいな感じでいいのでは |
送信元ユーザーの存在が必要なのは微妙 |
既存の通知カラムに表示 + クライアント起動時に画面全体に表示(アップデート時の表示みたいな感じで)とかはどうでしょう? |
通知は揮発性がある設計だから見逃して困るような重要な情報は置きたくないというのがある |
announcementに宛先ユーザーと表示の仕方を設定できるようにするのが一番良さそう |
表示の方法
|
あとバナー表示とかにする場合、新規ユーザー/長期間使っていなかったユーザーだと過去のお知らせの表示で埋め尽くされかねないから、お知らせの期限を設定できるようにしたり、登録以前のお知らせは既読扱いにするようにしたい |
期限を設定できるようにするのもそうだし、管理者が手動でお知らせを済んだものとしてマークできるようにしたい(削除だと後から見直せないのが不便そう) |
あとメールで送るかどうかも設定できるようにしてもいいかもしれないけど、読んだかどうかを判定できないからMisskey開いたときにすでに見たお知らせが再度表示されることになるのは微妙 |
やるか |
バナーとかダイアログで表示することを考えるとMisskey Web読み込み時に何らかの方法でannouncementsを取得する必要があるな |
metaで良いかしら |
metaに入れちゃうとキャッシュできなくなるな(announcementはユーザーによって異なる可能性があるため) |
あんまり読み込み時のリクエスト増やしたくないけどapi/announcements叩かせるしかないか |
効率のみ考える場合 api/i に入れるのが良さそうだけど不自然 |
既にhasUnreadAnnouncements返してるしそこまで不自然でもないか |
過去に送信済みのお知らせについて、管理者側が表示順を並び替えられる機能もあると嬉しいかなと思うのですが、いかがでしょうか?
というコメントから、お知らせとして置くべきものでは無いのかもしれませんが、重要度が比較的低いお知らせが上の方に残ってしまい、後から来た方が気付きづらいことがあります。 |
iに入れると非ログイン時にお知らせ表示できないわね |
全体としてのお知らせではなく、ユーザー個別に運営 or システムからお知らせを送りたい時がある
ユースケース
実装案
Related #7151
The text was updated successfully, but these errors were encountered: