users and users_preference tables design cleanup

[ehuelsmann]

The users table maps user names to user IDs (and to entities). The user_preference table lists the user's preferences based on the user's ID. The problem is that it does so by listing all preferences on a single row. This way, the users and user_prefence tables can be merged; another option (much more flexible) would be to list each preference on a separate row in the user_preference table.

[einhverfr]

The reason I currently split them up is that the permissions are different for the two sides.

I also agree that one row per preference would be more flexible and allow for add-ons to extend this.

[ehuelsmann]

Impact assessment:

• Need both a table with user-specific preferences and one with global preferences; possibly with some settings/defaults/preferences being restricted to the global scope only (much like settings);
• admin.sql has user preference functions
  • user__save_preferences() with a fixed list of preference "names"
  • user__get_preferences() which returns a fixed list of preferences (as "columns")
  • admin__save_user() instantiates user_preference record for any created users (but should not, to make the user's prefs and defaults fall back to the company-wide ones!)

[ehuelsmann]

Proposed design:

• Pivot user preferences table from current row-based setup to 2-column based key-value setup
• in case of explicitly requested setting: Query user settings primarily from user_preferences table, but in case of missing key, query defaults table (which returns the company-wide preference)
• in case of generic "select all" query: Query (for now) the keys (and values) from the users_preferences table unionized with the keys and settings from the defaults table

(It'll be some later change to factor out the company settings from the company wide defaults.)