Customization (additional) fields in downstream projects leads to massive fragmentation and makes maintaining these models harder. there is also duplication because of features that sometimes get backported to the library, but not all projects are then updated.
The idea is roughly to:
Add a JSONField for custom configuration options to the (base) model. Additional claim configuration can be stored here.
Add some sort of (unique) tag/identifier field so that we can associate a particular record with an authentication flow. E.g. public-auth and admin-auth, in case different identity providers are used with their own snowflake config
Drop the django-solo dependency/inheritance. This makes it easier since we no longer have to mock the django solo cache and take that into account, and instead we centralize all oid configs in a single table (and thus, admin list overview).
Configuration specific for the properties in the JSONField can be modeled with a classic django form which maps the fields from/back to their respective properties in the JSON field, allowing for a nice UX in the django admin without having to deal with JSON config blobs.
The tag/identifier mechanism could be used to signal the app that a particular record may not be deleted yet (e.g. project code can tell the application that a certain identifier is in use). The identifier could be used as the link for which config form needs to be rendered.
Data migrations or signals or something could be nice to ensure that records for all known/configured tags already exist (if created, empty/disabled by default) to remove the burden on admins.
This would also help managing the configuration for exports between environments (staging -> production) or to at least store the config in infrastructure-as-code, addressing the needs of #69
This is also a chance to address #45
This will lead to an interesting migration path w/r to backwards compatibility though :sweat_smile: but I'm confident we can figure something out.
Discussed in the office with Steven.
Customization (additional) fields in downstream projects leads to massive fragmentation and makes maintaining these models harder. there is also duplication because of features that sometimes get backported to the library, but not all projects are then updated.
The idea is roughly to:
public-authandadmin-auth, in case different identity providers are used with their own snowflake configConfiguration specific for the properties in the JSONField can be modeled with a classic django form which maps the fields from/back to their respective properties in the JSON field, allowing for a nice UX in the django admin without having to deal with JSON config blobs.
The tag/identifier mechanism could be used to signal the app that a particular record may not be deleted yet (e.g. project code can tell the application that a certain identifier is in use). The identifier could be used as the link for which config form needs to be rendered.
Data migrations or signals or something could be nice to ensure that records for all known/configured tags already exist (if created, empty/disabled by default) to remove the burden on admins.
This would also help managing the configuration for exports between environments (staging -> production) or to at least store the config in infrastructure-as-code, addressing the needs of #69
This is also a chance to address #45
This will lead to an interesting migration path w/r to backwards compatibility though :sweat_smile: but I'm confident we can figure something out.