Fasse's review comment on PR #2128:
Some more thoughts about the redesign of the preferences. We should also store these information in the database, but if we do it, we need to separate the values from the preference definitions so we need two tables, a preference table and the preference value table with this concept it would also be possible to allow user depending preferences. So the preference value table should have a column with the user ID.
What do you think about it?
My ideas:
- I wouldn't store preference definitions in the database. Preference definitions can also be added on-the-fly by plugins, and they are a more-or-less static description of the variables and possible values.
- However, adding a usr_id to the preferences makes a lot of sense. We have three different types of preferences:
- global preferences that apply to all organizations (e.g. future plugin store URL, core update, etc.)
- organization-scoped preferences (most of the preferences)
- user-scoped preferences (view language, themeing, start page, 2FA, etc.)
Fasse's review comment on PR #2128:
Some more thoughts about the redesign of the preferences. We should also store these information in the database, but if we do it, we need to separate the values from the preference definitions so we need two tables, a preference table and the preference value table with this concept it would also be possible to allow user depending preferences. So the preference value table should have a column with the user ID.
What do you think about it?
My ideas: