Skip to content
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

ノートの最大文字数を管理者が決められる機能を廃止 #8323

Closed
syuilo opened this issue Feb 16, 2022 · 12 comments
Closed
Assignees
Labels
☢️Breaking This change breaks compatibility ✨Feature This adds/improves/enhances a feature

Comments

@syuilo
Copy link
Member

syuilo commented Feb 16, 2022

Summary

  • 動的な文字数制限は静的なJSON Schemaに落とし込むことが出来ず面倒
  • そもそも管理者が決められる必要性が無さそう(3000文字もあれば十分そう)
  • この機能があることで、添付できるファイル数とかプロフィールの追加情報も最大数を管理者が設定できるようにしろという話が出てくる一因になる(当然そんなことやってたらキリがないし煩雑になる)
  • インスタンスごとで完全にバラバラであるよりもある程度統一されていた方が便利そう
  • どうしても最大文字数を変えたい場合はコード書き換えて、で良さそう
  • もし最大文字数変えたいというニーズがあまりにも多かったら設定ファイルで静的に設定できるようにするので良さそう
    • (設定ファイルにすることで

      動的な文字数制限は静的なJSON Schemaに落とし込むことが出来ず面倒

      は解決するため)

@syuilo syuilo added the ✨Feature This adds/improves/enhances a feature label Feb 16, 2022
@tamaina
Copy link
Contributor

tamaina commented Feb 17, 2022

私的には

  • 8000文字を上限にする
  • UIから残り文字数表示を削除
  • もし8000文字を超えたら投稿できないとエラーを出す

みたいな感じでいいんじゃないかなとも思った

@futchitwo
Copy link
Contributor

  • 8000文字を上限にする
  • UIから残り文字数表示を削除

おそらくユーザーに文字制限を認識させない意図があると思うけど、結局8000字を超えてエラーになるならその時何文字減らしたらいいかがわからないと不便だから、8000文字に近づいたら残り文字数を表示するくらいはしたほうがいいと思います

あとナンセンスな指摘かもしれないけど、8000文字かけたらそれはもはやミニブログではない気もする😅
ただ文字数の限界は広いほうが嬉しいだろうし(ほんまか)、数千字超えて設定してるインスタンスでも制限いっぱいのノートを見かけることはないので杞憂か

@syuilo syuilo self-assigned this Feb 17, 2022
@syuilo syuilo closed this as completed in a1c7c1f Feb 20, 2022
@Johann150
Copy link
Contributor

Johann150 commented Feb 23, 2022

Why was it not moved to the configuration file like you said initially? I know many instances that changed the character limit.

@Johann150
Copy link
Contributor

Also, I think this is a bad idea because it is a ☢️Breaking change.

@KawaneRio
Copy link

8000文字ってにゃんかキリが良くないので、8192文字上限がいいとおもふ。

あとナンセンスな指摘かもしれないけど、8000文字かけたらそれはもはやミニブログではない気もするsweat_smile

個人的にはMisskeyを自分のOSのログ日記とかねて使ふてるので、4000字では少し物足りないと思ふてた。

@KawaneRio
Copy link

あっ、Issue閉じてた。ごめんなさい。

@syuilo syuilo reopened this Feb 23, 2022
@syuilo syuilo added the ☢️Breaking This change breaks compatibility label Feb 23, 2022
@4ioskd
Copy link

4ioskd commented Feb 24, 2022

もし最大文字数変えたいというニーズがあまりにも多かったら設定ファイルで静的に設定できるようにするので良さそう
(設定ファイルにすることで
動的な文字数制限は静的なJSON Schemaに落とし込むことが出来ず面倒
は解決するため)

Johannが言うように、専用の設定ファイルを作ればこのissueは解決する気がする。

@Johann150
Copy link
Contributor

I still think that this behaviour is not backward compatible because it removes something from the public API. SemVer rule 8:

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

@syuilo
Copy link
Member Author

syuilo commented Feb 25, 2022

MisskeyはSemVerを採用していません。メジャーバージョンを上げるほどの大きな変更ではないと思います。

@nullobsi
Copy link
Contributor

If it is added to the migration, is it possible for the migration script on up to write the previous value to the config file? It would make a smoother transition.

@Johann150
Copy link
Contributor

If it is added to the migration, is it possible for the migration script on up to write the previous value to the config file?

This might be possible by adding it to the end of the file, but I'm not sure how the down would work in that case.

@syuilo
Copy link
Member Author

syuilo commented Mar 2, 2022

I don't think it is necessary to make it possible to set the maximum number of characters in a note in the configuration file yet, since there are not many needs to set the maximum number of characters arbitrarily at present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
☢️Breaking This change breaks compatibility ✨Feature This adds/improves/enhances a feature
Projects
None yet
Development

No branches or pull requests

7 participants