Add configuration store on server

[mtrezza]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Parse Dashboard has options that are:

• stored locally in browser, which makes them not persistent
• set via dashboard config file, which makes them difficult to maintain because they require code changes and re-deployment

Feature / Enhancement Description

Store options server side.

This can be easily achieved by specifying the class name to which options are written and from where options are read. It requires no changes in Parse Server code. It is also in line with the concept that Parse Dashboard deserves no special treatment (dedicated internal hidden classes, etc.) and is considered just another client from the viewpoint of Parse Server.

Parse Server should become the only place where options are stored, and the use of browser storage and config via file should be replaced by it whenever an option is moved to the server store. This solution opens up many possibilities in the future, for example user based settings in combination with _User based login #2311.

Example Use Case

• Store remote config history server side #2339

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

Suggestions:

Data

Add a new dashboard option on the app level, since config is managed and stored per-server app:

{
  apps: [{
    config: {
      userConfigClassName: 'DashboardUserConfig',
      systemConfigClassName: 'DashboardSystemConfig',
  }]
}

Because of #2311, the dashboard config should be stored in the class set in userConfigClassName with a single object, so that the class can later be populated with an object for each user. The fields names should imply the setting hierarchy like ´`, e.g.:

• user is the pointer to _User; the field can be added later with Dashboard login with Parse Server _User #2311.
• dataBrowserClassFilters contains filters, e.g.:

  [{
      className: '_User',
      filters: [
        { name: 'filterA', ... },
        { name: 'filterB', ... },
      ],
  }]

• dataBrowserClassColumns contains column order and visibility, e.g.:

  [{
      className: '_User',
      columns: [
        {
           name: 'columnA',
        },
        {
           name: 'columnB',
           hidden: true,
        },
     ],
  }]

Migration

If the config option is set in the dashboard options, then the settings should be read and applied only from the server. That means on initial dashboard launch no options will be applied because the locally stored config is ignored. There should be a button in the Dashboard to read the local config and store it on the server. The local config should never be deleted as part of the migration process for safety. If at any point in time the user removes the config from the dashboard options, then the dashboard will again read the locally stored config. The local config will persist beyond migration and can be deleted by the user manually by clearing the browser's website data.

1. User adds config option to Parse Dashboard.
2. User opens Parse Dashboard and click button "Migrate dashboard configuration from local storage to server."
3. Dashboard stores config on server, then reads and applies it.
4. If all works as expected, user can delete website data.

[dblythy]

@mtrezza I am thinking of replacing ColumnPreferences and ClassPreferences with an async version that uses Parse Objects that can either be saved locally or on the Db. I think we can probably use the same class "DashboardConfig" (or user can set) and then have a "class" column, rather than having one table per preferences.

[mtrezza]

The class name needs to be user configurable. No default value, as we don't know what classes already exist server side and can't have the dashboard overwrite anything in case of a generous CLP.

Could you spell out the data structure with sample values?

We need to prepare the config data structure for multiple users. That's why my suggestion to pack everything into one row and have one row per user. An admin could remove the user write permission from the row ACL, so a user can effectively not change dashboard settings.

I guess you could invert the structure and base it on class name, but there may be settings that are unrelated to a class. We could also base on the setting and have multiple rows per user and class. That would allow even more fine grained ACL.

Open to suggestions if you have a better concept in mind.

[dblythy]

I was just thinking of keeping it simple and having the object as:

• className (which table it is)
• columnPreferences (object with column preferences as they currently are stored in local store)
• classPreferences

And then we can add user or additional settings in the future as a different feature.

[mtrezza]

How would the data structure look like if we add per-user settings? Remember #2311. You could already think of the masterKey being a user, even though technically that's not really true.

See #2850 (review), that's a good example we can already incorporate in the data structure suggestion here. We need a schema that is able to cover all these options while still being structurally intuitive.

We need to consider:

• Race conditions: the schema needs to allow for atomicity, e.g. MongoDB a single JSON object in MongoDB allows that.
• Permissions: Each option can be set as editable or non-editable for the user to allow permission granularity.
• Mutli-user: Should allow for multiple users
• Multi-app: I think multi-app server is still a feature?
• Intuitive and easy to edit manually, e.g in Parse Dashboard.

Schema variants:

a) Pack all into a single object

Pro:

• fixed schema doesn't require Parse Server schema changes for new fields in the future

Cons:

• requires permission logic in beforeSave
• obj size limit relevant as all config is in a single obj

Field	Type	Description
user	Pointer<_User>	Reference to the dashboard user
appId	String	Identifier for the app this preference applies to
preferences	Object	JSON blob of all user preferences

Sub-schema of preferences:

{
  "collapsedSidebar": true,
  "theme": "dark",
  "defaultColumns": {
    "MyClass": ["createdAt", "status", "user"]
  },
  "lastVisitedClass": "MyClass"
}

b) Split into groups

Pros:

• Allows to load pref gradually, as needed, instead of all at once.

Cons:

• more maintenance effort and requires Parse Server schema changes for new fields
• requires permission logic in beforeSave
• obj size limit relevant as all config is in a single obj

Field	Type	Description
user	Pointer<_User>	Reference to the dashboard user
appId	String	Identifier for the app this preference applies to
theme	Object	theme preferences
defaultColumns	Object	defaultColumns preferences
maxVisibleRows	Object	maxVisibleRows preferences

c) Row per config

Pros:

• allows use of ACL for more granular permissions settings (writable, readable, per user, role, etc), no permission logic needed, as permissions are inferred from existing ACL logic
• fixed schema doesn't require Parse Server schema changes for new fields in the future
• Allows to load pref gradually, as needed, instead of all at once.
• document size limits irrelevant, because it's just 1 row per config item.

Cons:

• Maybe more complex to parse dashboard side, or maybe a "neutral" because it's easy to get all prefs of a user with query by user + appId.

Field	Type	Description
user	Pointer to _User	Which user this preference belongs to
appId	String	Identifier for the app this preference applies to
key	String	Name of the preference (e.g., "theme", or nested like "export.allRows" )
value	Object	Preference value of type Object to cover all value types

The value obj can hold any type, e.g. { value: true }, { value: 123 } or { value: 'abc' } so that there are no Parse Server schema definitions necessary.

Or to omit the verbose value obj:

Additional Pro:

• implies some type safety for pref values.

Field	Type	Description
user	Pointer to _User	Which user this preference belongs to
appId	String	Identifier for the app this preference applies to
key	String	Name of the preference (e.g., "theme", or nested like "export.allRows" )
boolValue	Bool	Preference value only set if type Bool
stringValue	String	Preference value only set if type String
numberValue	Number	Preference value only set if type Number
arrayValue	Array	Preference value only set if type Array

I'm leaning towards (c) at the moment, especially because of the ACL advantage and it's actually very easy to overlook all the settings. But let's discuss.

[dblythy]

I started working on this - specifically ColumnPreferences - but it's a bit difficult as they are currently synchronously saved to localstorage and updated any time a column visibility / reorder is changed. There's a bit of complexity here