Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework: change models to *not* be solo models #97

Open
sergei-maertens opened this issue May 1, 2024 · 0 comments
Open

Rework: change models to *not* be solo models #97

sergei-maertens opened this issue May 1, 2024 · 0 comments
Assignees

Comments

@sergei-maertens
Copy link
Member

sergei-maertens commented May 1, 2024

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:

  1. Add a JSONField for custom configuration options to the (base) model. Additional claim configuration can be stored here.
  2. 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
  3. 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 😅 but I'm confident we can figure something out.

@sergei-maertens sergei-maertens self-assigned this May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant