ephios is a django web application for managing participation for services at events, like paramedics at a festival, lifeguards at the beach, referees and judges at competitions, etc.
Is your feature request related to a problem? Please describe.
We're using Ephios with Keycloak as IdP. At our Keycloak instance, we assign users to groups (representing e.g. different working groups). On login, these group memberships are applied to the Ephios account as well (see #1105), which allows us to show certain events only to a specific group of people.
However, some Ephios features use qualifications instead of group memberships, for example the qualification mix shift structure. Currently, our only options are to use request and confirm as signup flow and check eligibility manually or create multiple separate events with the respective group-based visibilities. The first option is cumbersome for us and the second one may cause confusion among managers and users.
Describe the solution you'd like
Map qualifications from a (customizable) claim in the OIDC userinfo token. Qualifications of a user should automatically be updated each time they log in via OIDC again (just like groups do).
Describe alternatives you've considered
Combine the concepts of groups and qualifications into a single model that can be mapped from OIDC claims, used to restrict access to events (visibility, responsibility), and for shift structures.
Is your feature request related to a problem? Please describe. We're using Ephios with Keycloak as IdP. At our Keycloak instance, we assign users to groups (representing e.g. different working groups). On login, these group memberships are applied to the Ephios account as well (see #1105), which allows us to show certain events only to a specific group of people.
However, some Ephios features use qualifications instead of group memberships, for example the qualification mix shift structure. Currently, our only options are to use request and confirm as signup flow and check eligibility manually or create multiple separate events with the respective group-based visibilities. The first option is cumbersome for us and the second one may cause confusion among managers and users.
Describe the solution you'd like Map qualifications from a (customizable) claim in the OIDC userinfo token. Qualifications of a user should automatically be updated each time they log in via OIDC again (just like groups do).
Describe alternatives you've considered Combine the concepts of groups and qualifications into a single model that can be mapped from OIDC claims, used to restrict access to events (visibility, responsibility), and for shift structures.
Additional context none