Add competition creation allowlist via COMPETITION_CREATOR_GROUP

[cjh1]

This PR adds a configurable allowlist for competition creation using COMPETITION_CREATOR_GROUP.

Changes

• Added new setting in src/settings/base.py.
  • COMPETITION_CREATOR_GROUP (loaded from env, default empty).
• Added permission helpers and class in src/apps/api/permissions.py
• Updated competition create API permission in src/apps/api/views/competitions.py:
  • create now requires IsCompetitionCreator (instead of any authenticated user).
• Added enforcement in competition bundle completion flow in src/apps/api/views/datasets.py:
  • deny if configured creator group is missing.
  • deny if user is not allowed to create competitions.
• Exposed frontend capability flag in src/utils/context_processors.py.
• Updated UI buttons visibility.
• Documented env var in .env_sample.

Behavior

• If COMPETITION_CREATOR_GROUP is empty: authenticated users can create competitions.
• If set and group exists: only group members (and superusers) can create.
• If set but group does not exist: competition creation is disabled with explicit error messages.

Checklist

• Code review by me
• Hand tested by me
• I'm proud of my work
• Code review by reviewer
• Hand tested by reviewer
• CircleCi tests are passing
• Ready to merge

[Didayolo]

This should not be a .env setting.

Instead, we could for example:

• Have a can_create_competition boolean as a User's model attribute
• Have this to True for everybody by default
• Have an option to have it to False
• Then admins can go to Django admin interface to manually decide who can create competitions or not

@IdirLISN what do you think?

[cjh1]

@Didayolo I agree, that would be a better implementation, the reason I chose the approach I did is I wanted to avoid changing the schema. If changing the schema is acceptable, I can go ahead and update the implementation.

[Didayolo]

@Didayolo I agree, that would be a better implementation, the reason I chose the approach I did is I wanted to avoid changing the schema. If changing the schema is acceptable, I can go ahead and update the implementation.

Updating the schema is fine, especially if it is for a better implementation. Maybe Idir can give an opinion about the proposed implementation, but if you think it is good you can go ahead implement it.

[IdirLISN]

Hello,

Updating the user model is doable but not necessary as we can just verify if the user is admin (super user) or staff member (user who have access to admin page but with less rights than admin).

When someone create a competition, this endpoint is called: api/competitions/9/creation_status/
we can add a permission on this endpoint and add a rule to enable or disable the competition creation by everybody or not.

we will just need to add a new model to define a boolean like @Didayolo said to configure what kind of behaviour we want.

[cjh1]

@IdirLISN I am not sure I follow your proposed approach. Are you saying that only admin or staff should be able to create competitions? I would think we would like to be able to have fine grain control over who can create a competition, rather than bundling it in with other admin/staff permissions. Also api/competitions/9/creation_status/ is not the only path that can create a competition, there is also the bundle upload route.

[Didayolo]

@IdirLISN I am not sure I follow your proposed approach. Are you saying that only admin or staff should be able to create competitions? I would think we would like to be able to have fine grain control over who can create a competition, rather than bundling it in with other admin/staff permissions. Also api/competitions/9/creation_status/ is not the only path that can create a competition, there is also the bundle upload route.

I think what he's suggesting is having a platform-level option "can everybody creates competitions?"

• If True, everybody can create competitions
• If False, only users marked as "staff" (but not necessarily "superuser") can create competitions

@IdirLISN Is it what you had in mind?

My view was to have a new user attribute "can create competitions", a boolean serving this purpose. It is not very different anyway, we just need to choose, implement it, and clarify the documentation.

[IdirLISN]

@Didayolo Yes this is what i mean but it depends on the needs and the feature usage.

Behaviour excepted by @cjh1:
If COMPETITION_CREATOR_GROUP is empty: authenticated users can create competitions.
If set and group exists: only group members (and superusers) can create.
If set but group does not exist: competition creation is disabled with explicit error messages.

The competition creation needs to be deactivated by default

[Didayolo]

The competition creation needs to be deactivated by default

I think by default all users should be able to create competitions

[cjh1]

Just to summarize what we are working towards. The current behaviour is that all users can create competitions. We want to be able to control which users can create competitions and that control should be independent of whether they are admin or staff, as making them staff or admin would give them more permission that we would want.

[Didayolo]

Just to summarize what we are working towards. The current behaviour is that all users can create competitions. We want to be able to control which users can create competitions and that control should be independent of whether they are admin or staff, as making them staff or admin would give them more permission that we would want.

Yes, exactly. And I think we want to implement this in an elegant way, typically with a simple boolean per user that we can update in Django admin.

[cjh1]

ok, if that is the preferred approach I can go ahead and do that.EWe want a global control to turn off the current behaviour that everyone can create a competition, so this fine grain control can be used?

[Didayolo]

ok, if that is the preferred approach I can go ahead and do that.EWe want a global control to turn off the current behaviour that everyone can create a competition, so this fine grain control can be used?

Yes, let's have:

• A global option
• An individual boolean / Django permission