Results 228 issues of Sayamame-beans

## 💡 Summary 通常のノートで引用を選択した場合、投稿文を空にして投稿するとRenoteになります。 これは、Renoteの公開範囲を指定する場合などに利用することが出来ます。 しかし、ノートのURLを投稿フォームに貼り付けて引用化した場合、投稿文を空にしてRenoteすることが出来ません。 これはチャンネル内にノートをRenoteしたい場合などに影響があると考えられます。 Related? : #10598 ## 🥰 Expected Behavior 通常の引用Renoteと同様に、URLを"引用として添付"した場合でも投稿文を空にして投稿するとRenoteになる。 ## 🤬 Actual Behavior URLを"引用として添付"した場合は投稿文を空にして投稿することが出来ない。 ## 📝 Steps to Reproduce 1. ノートのURLをコピーするなどして取得する 2. 投稿フォームを開く 3....

packages/frontend
⚠️bug?

## Summary 今のところ、ファイルの閲覧注意フラグを変更したとしても他のサーバーには(一度届いてから後は)一切反映されません。 これ自体は"ドライブ"システムによりファイルエントリ(?)を再利用することに起因する致し方のないことだと推測出来ます。 ですが、ドライブ画面から閲覧注意フラグを切り替えられる以上、例えば画像の閲覧注意設定を付け忘れて投稿してしまい、それを変更して、ノートを再投稿したとしてもその変更が反映されないのは非直感的で、不便であると思いました。 また、サーバーごとに規約が異なることによるモデレーション上の厄介な点もあります。(リモートで付いているがローカルで付いていない場合の対処) 更に、閲覧注意がファイル単位ではなくノート単位で適用されているため、閲覧注意が本来付いていないファイルにも閲覧注意が付与されてしまう問題があります。 そこで、現在は以下のようになっているところ、 - 画像の閲覧注意フラグはいつでも変更可能 - リモートでは、ノート内の新規ファイルの1つにフラグが付いていたら、その他の新規ファイルにもフラグが付く(恐らく、ActivityPub的にノート単位でのフラグになっている) - ローカルではいつ変更しても反映されて、リモートでは新規ファイルが認識された時点のフラグを利用し更新されない 以下のようにするというのは実現可能でしょうか? - 画像の閲覧注意フラグ自体はいつでも変更可能(変わらず) - リモートでもファイル単位でフラグが反映されるようにする (ファイル単位のフラグ情報を、ActivityPub用のフラグ情報とは別に用意する) - ローカルではいつ変更しても反映されて、リモートでは新規ノート認識時の閲覧注意フラグを利用する (画像が別のノートで投稿された場合に、フラグの変化が反映されるようにする) ~~懸念点として~~ - ~~新規投稿かRenoteかを区別することが出来るのかどうか~~ ~~(区別することが出来なければ、任意のリモートからのRenoteで更新されてしまいそうです。元サーバーからの更新だけ反映するようにしたとしても、ローカルでモデレーションとして閲覧注意を付与したものが元サーバーからのRenoteで剥がされる可能性があると推測します。)~~ ~~があります。~~ 追記: ActivityPub上では、新規投稿はCreate、RenoteはAnnounceとして区別されているので、その点については大丈夫という情報を頂きました。...

✨Feature

## 💡 Summary 「見たことのあるRenoteを省略して表示」という文言からは、リアクションしたノートのRenoteを省略して表示するという挙動が分からないです。 #11166 で更に挙動が変わります。 追記: 「自分がRenoteした場合も省略して表示される」挙動の存在を忘れていました。 ## 🥰 Expected Behavior 「過去にリアクションしたノートのRenoteを省略して表示」 など ## 🤬 Actual Behavior 「見たことのあるRenoteを省略して表示」 ## 📌 Environment ### 💻 Frontend * Server URL: https://misskey.niri.la *...

⚠️bug?

### 💡 Summary webhookの設定項目において、「リアクションがあったとき」という項目があります。 (微off-topic: 「リアクションされたとき」?) しかしながら、 #8457 での実装時から[これまで](https://github.com/misskey-dev/misskey/tree/b0030d148db99b76d6283a8692a89671760665d0)、`type: 'reaction'`についてのwebhookDeliver処理は存在しないようです。 ### 🥰 Expected Behavior reactionされたときについてのwebhook送信処理が存在する ### 🤬 Actual Behavior reactionされたときについてのwebhook送信処理が存在しない ### 📝 Steps to Reproduce _No response_ ### 💻 Frontend...

⚠️bug?

### Summary 現在、リノートの項目に引用リノートも含まれています。(返信には含まれない) そのため、引用リノートを取得するためにはリノートを全て取得する必要があり、冗長なため、引用リノートを個別の項目に分けて欲しいです。 ### Purpose 自分に対する言及を転送する場合、必要な項目は返信, 引用リノート, メンションの3種類であるが、現在の仕様では通常のリノートも含まれてしまうため。 ### Do you want to implement this feature yourself? - [ ] Yes, I will implement this by myself and send...

✨Feature

### Summary タイトル通りです。 ### Purpose 何らかの理由( https://github.com/misskey-dev/misskey/issues/13316 関連など?)で通知を消したい場合があります。 現状、発生した通知を消す方法は存在しないため、消せるようになると良いと思います。 ### Do you want to implement this feature yourself? - [ ] Yes, I will implement this by myself and send...

✨Feature
🔥high priority

### Summary 凍結してもノートの情報は残り、通知欄に表示され続けてしまう(はず)ので、消えるようにして欲しいです。 即時が望ましいですが、即時でなくても(リロードが必要でも)良いと思います。 Related?: https://github.com/misskey-dev/misskey/issues/7198 ### Purpose スパム等によって発生した通知が消えない ### Do you want to implement this feature yourself? - [ ] Yes, I will implement this by myself and send...

✨Feature

### Summary タイトルの通りです。 通報が多く届いている場合などにごちゃ混ぜになったり、ローカル/リモートでフィルタリングしているのが解除されたりと、結構不便なので、元の状態を維持することは出来ないでしょうか…? (通報対応ページから、ユーザーページという全く別のものに飛んでいるので厳しい気はしますが) off-topic: ローカル側で凍結した後に、リモートに通報を転送した場合って上手く届くのでしょうか… ### Purpose 通報対応のストレス源を減らす ### Do you want to implement this feature yourself? - [ ] Yes, I will implement this by myself and...

✨Feature

### 💡 Summary フォローリクエストを承認、または拒否した後、通知を読み込み直すかMisskeyを開き直すと、再度フォローリクエストの承認/拒否ボタンが表示されます。 Related? - https://github.com/misskey-dev/misskey/issues/10611 ### 🥰 Expected Behavior フォローリクエストを1度処理した後はボタンが表示されない。 ### 🤬 Actual Behavior フォローリクエストを処理した後もボタンが表示される。 ### 📝 Steps to Reproduce 1. フォローリクエストを受け取る 2. 処理する 3. ブラウザのタブをリロードする(または通知カラムをリロードする) 4. 復活する...

⚠️bug?

### Summary Discordには、二要素認証を設定していないとモデレーションが行えないようにする設定が存在します。 Misskeyでも二要素認証が利用可能なので、モデレーション操作等を行う際に必須に出来るオプションがあっても良いと思います。(メール認証についても同様?) 微Off-topic: コンディショナルロールの条件にしたり出来ても面白いかもしれません。 ### Purpose 安全性の向上 ### Do you want to implement this feature yourself? - [ ] Yes, I will implement this by myself and send...

✨Feature