-
-
Notifications
You must be signed in to change notification settings - Fork 6k
Move UI configurations that do not require restarting gitea to take effect to the admin dashboard #33909
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
Conversation
models/migrations/fixtures/Test_MigrateIniToDatabase/system_setting.yml
Outdated
Show resolved
Hide resolved
The old configuration in setting module should be removed to reduce confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but I do not think this change is right.
Most setting options here are "user settings", it should belong to user's preference.
Sorry but I do not think this change is right.
Most setting options here are "user settings", it should belong to user's preference.
Now the migration is the configuration in the ini file, these configurations currently belong to the global configuration, not the user preferences, you mentioned the user preferences configuration we will implement in the next pr, what do you think?
Now the migration is the configuration in the ini file, these configurations currently belong to the global configuration, not the user preferences, you mentioned the user preferences configuration we will implement in the next pr, what do you think?
If there is a widely-known roadmap, then we can "implement it in the next pr".
For this feature, at least it is not clear to me what's your plan. What the final solution look like?
- Should we keep or remove these ini options?
- If keep, how to make the ini-options and db-options co-exist.
- If remove, how to make users could set initial values for the config options.
- What the user-setting system would look like.
- If an option should be a user option, how to make it work with system option?
- What kinds of options should be supported?
- ini-only option
- system-wide db option (inherit legacy ini option?)
- user-setting db option (inherit system-wide option and inherit legacy ini option?)
Most setting options here are "user settings", it should belong to user's preference.
no, I think they are performance related config options for web service, They will directly affect the performance overhead of the server. so it should not be configable for all users.
Most setting options here are "user settings", it should belong to user's preference.
no, I think they are performance related config options for web service, They will directly affect the performance overhead of the server. so it should not be configable for all users.
Are you sure they should not be configurable for users? For example, not only one user mentions that they want to customize the default sort option like EXPLORE_PAGING_DEFAULT_SORT.
See the comment above: #33909 (comment) : clarify the config options first.
Most setting options here are "user settings", it should belong to user's preference.
no, I think they are performance related config options for web service, They will directly affect the performance overhead of the server. so it should not be configable for all users.
The database query is fast enough and I don't think we need to worry about it will impact performance.
The user level configuration could be another PR since this one's task is moving them to database so that a global change will not require restart Gitea instance.
If the paging size is freely configurable by the user, it will greatly affect the performance of the server.
There is currently a debate about which configurations, are available as user preferences, and I think we can discuss options here.
These questions should have clear answers first.
replace: #33740
image