Welcome to GCAB Web

Notes

• Very little styling and even less responsiveness. The idea here is to work out the data model and make sure we know how to get to all the data needed per page.
• The menu is a CSS-based thing I just invented. Seems to work well but there may be quirks. It's not data-driven yet, but I think it could be easily (so based on who's logged in, different options appear). Need to work on responsiveness here as well.
• Uses Microsoft's Identity framework code that does the heavy lifting on creating user account, registration, login, change password, edit profile.
• The GCAB Person object is a combination of an person and an Identity User (Account). All Users are Persons, but not all Persons are users.If the IdentityUserId and IdentityUserName are null, then this person doesn't have an account. This is how a manager can add people and then send invitations, for example. It is also how someone adds himself to the player pool (they become a person, but not a user). Then, if claimed, the manager adds them to his roster, sends an invitation, and they become a user once they register.
• Currently functional, if not pretty:
  • Season
    • Schedule
    • Scores
    • Standings
  • Teams
    • Team listings by division and conference (where applicable)
    • Team details
      • Team information
      • Games (schduled and results) for current season
      • Team personnel. Roster and non-roster helpers.
      • Edit roster. A work-in-progress, but allows a person who has the proper permissions to add, edit and remove team personnel. If you don't have permission, you won't see the "Edit Roster" link.
  • Fields, both listing and detail pages. Detail page includes the map links from the current GCAB site.
  • User: Rudimentary Login, Edit Profile, and Logout.
• Lots of pieces of this data model are qualified by season. Right now, The divisions - conferences - teams (in the data model, this is called SeasonStructure), as well as the Schedule, Scores, and Standings. Fields are not.
  • If there is no querystring, the current season is displayed (the CurrentSeasonId in the League table). To see a specific season, add ?season=2025 to the end of the url.
  • Try it on the Teams page. In 2025, you will see the 60s division as 8 teams. In 2026 (current), it will be two conferences of 4 teams each.
  • BTW, with this structure, we can actually track a single team as it moves across divisions. Or a person, as he moves from team to team over the years.
  • TeamPerson is also season-dependent. The Edit Roster will only be available for the current season.
  • Permissions are not season-dependent. They always represent current-state.

Ideas

• Since all players will have an account, we can make a personalized home page if someone is logged in. The default / anonymous home page is the usual marketing stuff. But logged in, we can show the upcoming games for a player (on all his teams), and announcments for the divisions he's playing in. Depending on other roles the person might belong to, we could have direct links for getting things done (cancel a game for the scheduler, for example).
• I'd like to add an Export To Calendar option on the Team page, near the Schedule. I have some sample .ics files in the wwwroot folder.
• Allow managers to comment on players in the player pool...problems contacting them, lack of experience or commitment, etc. Maybe even give them a checkbox to "Please remove this player from the pool".

Questions / To-do / Bugs

• Big To-Do items:
  • Done Design and implement the permissions model. This says who can do things like edit the team roster, report scores, update other team information (like pictures & team notes), send notifications, etc. Likewise, this model will allow for "league-wide" permissions, like change schedule, cancel games, or maybe just change game location and time. Probably a team-wide and league-wide "set permissions" permission as well. There will be roles, which are just bags of permissions. So, a manager role will have a number of permissions on his team, while a scorekeeper role may only have Report Score permission.
  • Done Design the team - person relationship. This mostly means players, but we also have to consider helpers / scorekeepers associated with the team, that don't count as roster spots.
  • Score reporting.
  • All editing. Right now, this is entirely read-only. Much easier to display info than to collect and update. Edit Roster is Well under way.
  • Work out the "user invitation" process. Generally, someone will add a person, including their email, to the Person table. At this point, even though they're not a user, they can be aded to a roster and assigned permissions (roles). An invitation will be send via email, with a link. When the user clicks on the link, that confirms the email and activates the user account.
  • Allow players and assistants to sign waivers. Maybe somehow link the waivers needed to a Role on the team. Display eligibility on the roster.
  • Done Figure out how to properly get errors to show up back to the user. I see code that uses ModelState, but the error is not displayed on the view:
    if (result.Succeeded) return RedirectToAction(nameof(Index)); foreach (var e in result.Errors) ModelState.AddModelError(string.Empty, e.Description); return View(model);
• Other To-Do items:
  • Done Add emergency contact information to Person.
  • Done Move the Identity (user/role) database access code into my data framework, rather than the embedded SQL that ChatGPT generated for me. Write appropriate stored procedures. Also, clearly identify those pieces that are part of Identity by prefixing their names with Identity (table names, sp names, class names, column names in Person, etc.).
  • Refactor. Things that come to mind are styles that I may have embedded into .cshtml files for convenience (these should mostly be in site.css unless highly specialized for the view). Also, the display of a list of games in (scores, schedule, and the team details pages are mostly copy/pasted. These should be combined into a partial view that can be included into each of these pages.
  • Under way Clearly understand the distinction between Model and ViewModel (I am not yet using ViewModels but they belong here I think), and refactor (plus restructure the folders) accodingly.
  • Consider whether a Services layer would be useful. In my experience, if there is too much code in the controllers, especially duplicated code, that means you should consider a service layer. I don't think we are there, and if it is not needed, a Service layer can be just tedious.
  • The About pages.
  • Done Seasonal structure changes are accomodated by this model pretty well. So well in fact, that one thing keeps annoying me. For prior seasons, the current manager is listed as the Team manager. We might want to adjust the data model so that the team - manager relationship is qualified by season-id as well.
  • Get the connection between MakeupOfGameId and RescheduledGameId (should we have both?), and display it properly wherever games are shown (scores, schedule, team games).
  • Add the list of games to the Field details page as well. This is helpful for reconciling invoices.(I'd even consider adding a hidden "paid" column for each field/game that only the Treasurer role can see. :)
    BTW, this will require the addition of ?season=xxxx as a query parameter, since the schedule for that field during that season will be displayed.
  • It'd be awesome to migrate whatever seasons' data we have in the current DB into the new one. It would help test things, plus give us a history. For example, on a player's profile page, we could list all the teams he has been on historically. NOTE: players / rosters will probably be the most difficult to migrate, since we don't have any key information, just name & age.

From Pete's Email

• Players will have their own login and manage their own profiles. They will be authenticated via their cell phones using a OTP (One-Time Password). They will "register" for their profile for free. A OTP will be sent to them to validate (initial registration) and access (subsequent management) their profile. [Note: this will diminish the potential for managers to complete waivers for players BUT a player will now be required to have to have a cell phone with SMS capability to complete their waivers. It should be discussed whether this presents a barrier or hardship for any player]. The player managed profile will allow players to login at any time to set or edit their contact and/or emergency contact info as a part of completing their online waiver. The benefits are; they can change their contact and/or emergency contact info at any time and also one waiver will suffice if they are playing on multiple teams. They may opt in or out of the alert system within their profile. WE SHOULD CONSIDER WHETHER WE REQUIRE PLAYERS TO REGISTER FOR THE ALERT SYSTEM EVERY YEAR OR WHETHER THEIR OPT IN IS MAINTAINED YEAR OVER YEAR UNTIL THEY OPT OUT.
• Managers will manage their rosters up until July 15th. These changes may occur as often as a manager wishes and carry no per change fee. IF THERE IS TO BE A TIME LIMIT FOR CHANGES BEFORE A GAME THEN THIS WILL NEED TO BE ADDRESSED BY THE BOARD AS TO THE TIME LIMIT. All changes will be recorded so managers within that division can see all changes by every team within that division. Changes after July 15th will require board approval. THE BOARD WILL NEED TO DETERMINE IF THERE IS A FEE FOR CHANGES AFTER 7/15.
• Free Agent Pool players will be required to validate an email and phone number before their submission goes live. This provide a mild barrier to entry. The language for free agent pool submission will make more clear the commitment they are subscribing to in hopes of filtering out those less serious pool players.
• Managers should be reminded of game recap intentions and proper protocols for what they may include in recaps. Per Mike Morel's suggestion a few months ago, I will create a user role for the board so that board members may edit manager submitted recaps.
• We are looking for new images for the web site that illustrate "competitive", "amateur" and "competitive". We sought images from the managers in the past but had very few submissions.