cms-dev
Add ability to assign only certain contests to an admin user
Currently, an admin user (created with cmsAddAdmin) manages all contests. I would like to be able to assign an admin user to only one contest (or to more than one contests).
Use case: with the multi-contest feature, it happens that some users wants to organize and manage (as admins) a contest, but they may also want to participate (as contestants) to a different contest.
By the way, why don't we ditch the Admin entity and just add a Participation.is_admin field?
Thinking about it, I think that the existing Participation.unrestricted and the "proposed" Participation.is_admin could very well just be a single boolean field.
How would that work? If flag is in Participation and Admin and User structures are kept it would break all the code requesting User from Participation. If Admin is removed, but admin flag is in Participation, how do you create a contest and mark participation as admin without any admins?
I'm not sure I understood, but I was thinking about removing Admin (and in that case, the cmsAddAdmin command would take care of having the admin participate in the contest).
cmsAddAdmin can only add admins to existing contests. From your previous description I assumed that this was supposed to work with long term accounts. Also there is large amount of options in AWS which are not contest specific: managing admin accounts, creating new contest, managing services.
@stefano-maggiolo @lerks what do you think about this? Especially the part about making the Admin users be just normal Users with "privileged" Participations to contests.
Can I rename this feature request to "Merge Admin in User" or something like that? 😄
I think your proposal needs to be refined before it can be properly evaluated.
For example, since the proposed "is_admin" flag would only be on participations (i.e., bound to a certain contest), who will be allowed to create new contests (and users, and teams)? All users? Those that are admins on all contests? A special type of "super"/global admins?
One possible fix to this problem would be to add an "is_admin" flag to users as well. Yet this starts to become a bit too complicated...
Could a workaround be adding an optional field to Admin users, which specifies a list of contests that they can be admin of?
That is, if the list is empty then the admin is admin of every contest, whereas if the list has 2 elements then the admin is admin of just those 2 contests. The only problem is maybe how to update this lists in case of Contest deletion.
EDIT: actually it doesn't really matter if the lists will contain "not-existing-anymore" contests IDs, as long as the IDs can't be reused (e.g. a new contest being created with the same ID as a previously deleted contest) which I think is guaranteed by postgres.
I don't like it, it feels like bad database design.
If you store contest names in the list you need to keep it up-to-date when a contest name changes.
If you store contest IDs you need to make an exception to the generic machinery we're using to export and import contests.
And, AFAIK, there's no way of storing foreign keys in a list.
The closest thing to what you want is a many-to-many relationship. That I could be OK with.
Yes but that would mean creating an "AdminParticipation" concept, where each admin 'participates' as in 'administers' many contests.
If we opt for this solution, really, we should just merge Admin and Users and re-use the existing Participation entity. It's just too ugly doing otherwise...
I think I need to understand better what you want per-contest admins to do. Moderate messages? See and edit testcases? Create tasks? Create contests?
If the answer to the last question is no then we need some way for admins to be "unbound", and be able to have full powers on all contests.
Good points... well, I think I would be happy if they could at least moderate messages and see/edit testcases, maybe even cloning datasets (and activating them).
I don't see an immediate reason to let them create users/tasks/contests/participations.
So, here is one option (I'm still brainstorming, I'm not saying it's a good option). We could put Admins "at the same level" as Participations, that is, add to Admins a foreign key to Users (with the constraint that there's only one Admin per User). Then, in the same way tha a User can log into a Contest only if there exists a Participation in that contest for that User, a User can log in as an Admin only if there is an Admin for that User. Hopefully this wasn't too confusing.
Moreover, to satisfy your needs, we can add a Moderator (for lack of a better word, for now) object that, like Participations, has a foreign key to both a Contest and User. A User that is a Moderator for a Contest can log into AWS even if they are not an admin and perform some limited actions on that Contest only. ("Real" Admins would be implicit moderators for all contests, of course.)
What do you think? Technically, this seems a satisfying solution to me (@stefano-maggiolo please weigh in). But does it solve your issue?
Yes I think it would. Maybe it would make sense to also rename the "participations" table in "contestants" so that we have the two natural concepts of "contestants" and "moderators".
EDIT: but wait, at that point is just easier to have a boolean flag is_also_admin in the "moderators" table, isn't it?
EDIT2: hmm ok the root problem here is that we need to have some "global" admins for all contests instead of having to add moderators/admins everytime.