[FEAT]: Basic actions required for admin end of application

[majorbruteforce]

• Register : Register players, teams and referees/umpires, and store them in database so they can be made available while creating games.
• Creating games: The scorers can create a new game which takes in players, teams and game orientations. New players can be added on spot. Games can be paused and deleted.
• Scoring games: The games can be scored by sending 'events' which are a snapshot of the game a particular instance containing all parameters for the set orientation. Events can be independently stored for each game to view the game and undo events.
• Update standings: The standings can be manually updated to cater for unavoidable circumstances.

Please list down other necessary features and suggest API endpoints to implement each feature in this thread.

[zakhaev26]

For registration,what I have planned is :

• Players will choose their specific sport, the UI adjusts the form accordingly. Upon completion, the form data will be sent to the respective API server.
  that's why the API route should look something like this which will be used by the client:
  http://<ip>:<port>/<sport_name_in_small_case>/registration

That way each dev can easily cater to the registration requirements of their sport.The data will be stored in the player collection within their designated <sport_name> db.

[majorbruteforce]

I have another suggestion (inspired from CricHeroes). We can let players register themselves with their credentials (which should be independent of the sport they are playing and their roles in it). This will be stored in a general database. Later, the team captain or admin will register teams for tournament where they will select the players and assign roles and specific details (if required, usually there is no need unless stats are to be recorded).
We can have a general API route:
POST https://<domain>/register/<player-name>
While registering a team:
POST https://<domain>/register/<sport>/<team-name>
this will take all necessary details about the team and the players in the body and create a separate collection in the database for the specific sport.

This model will prevent unwanted registrations and allow the admin to have more control.

[majorbruteforce]

We will also have to make routes to register admins/referees who will score the game. Additionally, we have to store the information about who was responsible to score a particular event in the game or a game itself.

[zakhaev26]

A sytem for Player registration and Captain uploading their team roster has been made here, will be working towards improving that + making one for the admins/referees.

[zakhaev26]

@AnirudhParida @majorbruteforce @punitkr03 for the registration of players (to be done by the captain),is there any other way to simplify the process or this is good?

1. All the registered players will be kept in a generalDB.
2. Captains will be uniquely identified by secret passkeys,after they log in they will have option to select/update the roster
3. in every case the verified (by verified i mean email-verified) + that particular team + sport only players will be pulled from the generalDB
4. The Cap selects the players and then we open a transaction in both the dbs so that the isInCurrentTeam bool can be made true,so the next time cap wants to update the team members,they will know that these players are currently in the team,these are not,so accordingly he removes/adds.

eg : Captain of football - EEE comes to select players,only verified - football - eee players will be pulled from generalDB and then the process as mentioned.

[zakhaev26]

Ref : #13 (comment)

PS:IMO making databases for each sport makes it difficult to manage and whatever operation we will be doing (lets say football apis,basketball apis etc) can be performed in a single database.

[punitkr03]

@zakhaev26 Monolithic DB will be challenging in the long-term and for future developments. We can keep both imo.

[zakhaev26]

The Auth API and Mailing API have been completed. Since this issue has remained unresolved due to changes in the application's build process, a new one (#33) has been opened. We are now closing this one.
CC: @majorbruteforce @punitkr03