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.