Provide a `Settings` entity with key, value pairs

A new database entity for storing configuration data.

Motivation

This can be used for many different scenarios. Just two name two of them:

Storing possible link types

With the new Link model we are missing a way how different link types are identified. This is the main reason from which this ticket emerges. While doing the migration from the o94 legacy backend data, it's not clear how to pass e.g. CBA, Website or any other type of links.

For example previously a timeslot.note did have a specific field for the CBA Link. Since this is now generalized, any API consumers do not know how to store Links to the CBA. A Link entity has the properties description and url. To create a new CBA Link record, a client will e.g. populate the property description with link_type_cba and the property url with the actual URL.

Now, how does an API client know, which identify it should provide for the link type? Where does it retrieve the information from, that CBA Links are identified by link_type_cba?. How does it even know all the link types which are allowed within a radios infrastructure.

This case would be solved by such a Settings key/value store.

A place to store global Web Application configuration

The Dashboard can store an radio-specific settings, which require a more dynamic approach than static config files.

Thoughts on implementation

• It might me wise to not only provide key and value pairs, but also a namespace field. The enables grouped queries of e.g. all config records of the type link_type.
• A way to define some pre-defined set of mandatory settings (like Fixtures)
• Think about not using the Link field description but defining link types, but adding a specific field type. This is because "description" indicates a human-use perspective, while the "type" is meant for pure machine-use. We also want to avoid that Use Case appear that people mix and match the same field for machine- and human-use.
• Provide API endpoints to deal with the Settings entity

changed milestone to %1.0-alpha2 — ⚖️🐦 Precise Pheasant

added discuss label

On 07.09.22 @nnrcschmdt and I decided that the Settings will be implemented using native Django Settings. These settings will be exposed by an API endpoint.

Settings currently covered:

• Link types (e.g. link_types = {'cba': 'CBA', 'soundcloud': 'Soundcloud'}
• License types (e.g. license_types = {'cc_by_nc_sa_2': 'BY-NC-SA 2.0', 'publicdomain': 'Public Domain'}

marked this issue as related to #124 (closed)

I think we can get rid of the keys, and only use/save the selected type in the instance of Host, Show, Note.

This way, it will remain consistent if/when the link or the license type is no longer supported.

LINK_TYPES = (
    "Homepage",
    "Cultural Broadcasting Archive Post",
    "Cultural Broadcasting Archive Podcast",
    "SoundCloud",
)

LICENSE_TYPES = (
    "Public Domain",
    "Creative Commons Attribution",
    "Creative Commons Attribution-ShareAlike",
    "Creative Commons Attribution-NonCommercial",
    "Creative Commons Attribution-NoDerivatives",
    "Creative Commons Attribution-NonCommercial-ShareAlike",
    "Creative Commons Attribution-NonCommercial-NoDerivatives",
    "GNU Free Documentation License",
)

Given your suggestion, how would you realize a HTML dropdown client-site, like this example below. Note the required value

<select name="episode_links" id="episode_links">
  <option value="website">Website</option>
  <option value="cba_episode">Cultural Broadcasting Archive Post</option>
  <option value="cba_podcast">Cultural Broadcasting Archive Podcast</option>
  <option value="soundcloud">SoundCloud</option>
</select>

This also means, that:

• with every API interaction you will have to have knowledge on the exact string to be posted
• it's hard to almost impossible to change the display value for e.g. all links. Maybe you want all frontend to display "CBA Post" instead of "Cultural Broadcasting Archive Post" in the UI. That would mean you have to update all records which use this link type.

You are right.

We are going to need the keys.

The API should accept the keys and save the current values in the database.

LINK_TYPES = {
    "homepage": "Homepage",
    "cba-post": "Cultural Broadcasting Archive Post",
    "cba-podcast": "Cultural Broadcasting Archive Podcast",
    "soundcloud": "SoundCloud",
}

LICENSE_TYPES = {
    "pd": "Public Domain",
    "cc-by": "Creative Commons Attribution",
    "cc-by-sa": "Creative Commons Attribution-ShareAlike",
    "cc-by-nc": "Creative Commons Attribution-NonCommercial",
    "cc-by-nd": "Creative Commons Attribution-NoDerivatives",
    "cc-by-nc-sa": "Creative Commons Attribution-NonCommercial-ShareAlike",
    "cc-by-nc-nd": "Creative Commons Attribution-NonCommercial-NoDerivatives",
    "gfdl": "GNU Free Documentation License",
}

assigned to @nnrcschmdt

added P2 label

removed discuss label

@nnrcschmdt I had some more thoughts on the approach of using Django Settings for app configuration:

Right now, I'm not sure if it's good to configure app specific things in a static config file or even environment variables, because:

• Build complex structure is much harder i.e. how would you reflect above structure in an environment variable? As a results the config approach is more error prone for inexperienced users.
• You have to restart the server if you want to modify the application configuration
• In the long run, I believe all app config should be done via a user interface (Steering admin interface). We should only config infrastructure things like database credentials or URLs of other services in the config file and docker compose.

Also compare meta#112+ where we are trying to simplify configuration. The Django configuration file approach would make things harder, in my opinion.

added discuss label

Using static config settings requires a restart of the application to reflect changes, but how often are we expecting to change link types a/or license types?

My rationale behind using settings: the database is arguably the wrong place to store this type of configuration and environment variables are, as you mention, only usable for simple settings.

Adding the database models and an admin interface for link types license types can be done, but I would rather not do it.

I think that providing a good set of default settings and documentation on how and where to change them would be better.

It's true, that these settings will not change very often. But IMO that doesn't matter. It's more a matter of convenience. We are storing OpenID clients also in the Steering database, even though they will most probably never change again.

I'm curious where you would store such things then? Please note, that the current Docker Compose implementation is meant to only use environment vars. Maybe your thought is an important argument in the discussion over there. In the Docker Compose discussion we want to get rid of as many settings as possible. Currently configuring Aura is quite a pain because of configuration overload.

My reasoning is also, that we will need many more settings in the future and want to make an example which is simple to implement.

My rationale behind using settings: the database is arguably the wrong place to store this type of configuration

How come? It would be great if you could share some resource supporting your argument. Storing app specific settings in the database is actually a very typical pattern in software.

... We are storing OpenID clients also in the Steering database, even though they will most probably never change again.

Yes, but this is the way Django OIDC Provider does it. It makes sense that clients and IDs are stored in the database and not as settings.

This way one client can be added or deleted without restarting the whole application for every change.

And since the application already needs the database to store the tokens...

My rationale behind using settings: the database is arguably the wrong place to store this type of configuration

How come? It would be great if you could share some resource supporting your argument. Storing app specific settings in the database is actually a very typical pattern in software.

It is simple: by using the database, we are going to need the model, and are introducing the migrations and admin code (albeit it's very simple) is code that we'll need to maintain. And we may end needing either a set of JSON fixtures (like the recurrence rules) or even more code for a REST API.

If we use the settings file this is the only thing weed to maintain and keep in-sync with the documentation.

I'm a proponent of YAGNI and I would like to stop generalizing the code of Steering when it's not needed.

I admit it's a rather arbitrary where to draw the limit, but let's find it together.

I have given it some more thought and since it is a rabbit hole, I'm going to make models for LinkType and LicenseType, provide a simple admin interface, JSON fixtures and expose them in the REST API.

marked this issue as related to #126 (closed)

closed

Out of another conversation with @kmohrf regarding service configuration in Matrix, he pointed to LOHRO's thekno-env.json. This reminded me about the need of this ticket's original motivation.

Just wanted to leave this Link to the JSON here, as we might come back to this topic at a later stage.

mentioned in issue #173 (closed)

marked this issue as related to #173 (closed)

removed discuss label