View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017414 | mantisbt | db schema | public | 2014-06-05 02:26 | 2019-06-17 05:53 |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.2.17 | ||||
Summary | 0017414: User preferences vs. config tables | ||||
Description | The user preferences table currently has a strict schema with a field per user preference. Hence, adding new ones is a large difficult task and may not be allowed based on the release cycle. I prefer the model that we have used for configs where it is easy for core or plugins to leverage the standard infrastructure to add new configs at any time without schema changes. For example, let assume we want to start using configs to power new preferences or possibly even migrate existing ones to it. The issue is that we will pollute the configs with all these user preferences and we potentially will put data in the administrator's face that they may not want to see. So I wonder, if we can have a convention where any config with name starting with "userpref_" gets filtered out from the Manage - Manage Configuration page. It also makes sense to discuss whether we will adopt the full semantics of the config APIs including can have different settings based on the project, and default to some "all users" values when user doesn't have an entry specific to them. It would make life easier to use the same API and follow the same convention. | ||||
Tags | schema | ||||
related to | 0020323 | new | Update schema to support user preferences for more email events |