Open ahundiak opened 8 years ago
ahundiak
commented
8 years ago Future stuff:
ahundiak
commented
8 years ago Implementing some of the safe haven and concussion stuff helped to clarify some things. We really should have:
So the key is that for referees we have both a cert and a role.
So we should separate Cert and Role objects.
Probably won't go that far for ng2016. At least not until we get over the registration bump. The Role object has enough info to cover both cases. An active property is already being used to distinguish between the two. Might try interfaces for them.
Storing them in one table is a persistence detail which probably won't need to be changed until after ng2016. Even then, a bit of renaming might suffice. Simple name that implies for role and cert? Maybe details? Too broad. RoleCert or CertRole might do it. RoCe CeRo
ahundiak
commented
8 years ago Something to adjust for ng2016 is it starts causing problems. Certs should transfer from previous tournaments but roles should not at least in some cases. Probably be okay until formally split referee role and cert. Might be able to do this before registration.
ahundiak
commented
8 years ago
Roles can now be applied on a project specific basis. So for different tournaments, different people can have different roles. The built in Symfony security is still used so the same isGranted functionality will work as expected.
Any logged in user will always have ROLE_USER. So all the guest menus and stuff like that can key off of ROLE_USER. No need to use Symfony specific roles like IS_AUTHENTICATED.
A tiny number of logged in users will also have ROLE_ADMIN. Specifically, Rick and I will have ROLE_ADMIN. The Toms will have it to start just so they can see the admin menus during development but later they will be removed. The idea is that ROLE_ADMIN can do anything to any project.
The rest of the roles come from the projectPersonRoles table and can be controlled on a tournament basis.
When a person answers yes (or maybe) to the 'Will Referee' registration question then a ROLE_REFEREE record will be added. This role will then be merged in with their ROLE_USER. So anything referee specific can key off of isGranted('ROLE_REFEREE').
The role entity has a property for badge The role record also has properties verified and approved. The referee administrator can use these properties to control if the referee can actually sign up for games.
There will be additional roles that can be manually assigned. ROLE_TOURNAMENT_ADMIN ROLE_REFEREE_ADMIN ROLE_ASSIGNOR ROLE_SCORE_ENTRY ROLE_SCORE_ADMIN
Basically, we can fine tune as necessary. All of the above roles will also get ROLE_STAFF if we want.
I am also using roles to track additional certification. So, when applicable, we will have ROLE_SAFE_HAVEN ROLE_CONCUSSION ROLE_FLORIDA_VOLUNTEER (or maybe ROLE_STATE_VOLUNTEER)
Roles have an active flag. The above certification only roles will be inactive so you won't actually be able to do isGranted('ROLE_SAFE_HAVEN') because I don't see a need for it. But the administrator can still use the verified flags.
Reusing roles for these sorts of certifications is a 'trick' to simplify coding. It avoids the need for a different certs table. Time will tell if this is a good trick or a bad trick.