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.