The Players and Users sections can be hidden or left unresponsive until those features get added.

However, the menu needs to be streamlined to include current functionality. Not sure if the Edit links make sense, for example.

Once a lot of teams are added and attached to their respective leagues, this page will need to be a lot more compact and present the needed information. I'm thinking of three separate toggles, maybe more.

1. sort all teams alphabetically
2. group teams by leagues they are attached to
3. view only teams not attached to a league

Currently, when editing the Season end date, the application allows user to enter a date prior to start date and save.

Validation should happen to prevent this.

This can likely be done with the flatpickr javascript library, but I'd prefer to do server side validation using htmx.

This might be possible to do with jinja and htmx.

In the season-edit.html template, there is a conditional jinja block {% if show_end_date %} with logic tied to the async def get_season_end_date() method. Probably just need to add validation at this route.

If one of the scores is empty and you hit save, it causes an error:

msgspec.ValidationError: Expected `int | null`, got `str` - at `$.team_away_goals`

Having an empty value to begin with is desirable, as that can be used to assess that a game has not been played yet. But when one score is filled in, maybe it can default the other score to zero, or if you try to save with an empty value, it defaults to zero. Second option not the best, because wouldn't want to default to zero if both are left empty (on purpose) if the intent is to edit something else (like teams or start times).

The League index could use a redo (league-index.html). Can start by removing the "Tile View"

I'm thinking I will want some sort of toggle that sorts leagues alphabetically or groups them by season.

This should be consistent with editing leagues/schedules...

The jinja template should look for what is the current selected league for team, and have that option preselected. Following this pattern:

league-edit.html does this to preselect the league's current category:

<select name="category" id="category" class="bg-gray-50 border border-gray-300 text-gray-900 rounded-lg focus:ring-cyan-600 focus:border-cyan-600 block w-full p-2.5">
    {% for category in categories %}
    {% if category.value == league.category %}
        <option value="{{ category.value }}" selected>Current: {{ category.value }}</option>
    {% else %}
        <option value="{{ category.value }}">{{ category.value }}</option>
     {% endif %}
    {% endfor %}
</select>

When saving a field in the schedule edit view, the save changes the date field. I believe it is because it is sending a UTC time to the server, and then converting the time when sending the request back. Or vice versa, not sure which ...

Here is a schedule view before the change:

Then I add a score. Notice the date change:

This is the payload from the post request:

I'll have to check what date is being sent from the flatpickr library.

I haven't fiddled with dates all that much yet, so I suspect it's an issue of UTC and locale.

Adding a litestar serializer to the json logger configured in log.py could provide some performance upgrades:

Ideally, a user can end date a season to inactivate it. However, if this is done by accident, or the season needs to be extended, there's no intuitive way to extend the season. One way would be to simply remove the end date when editing the season.

However, that currently throws an error.

It appears that the DTO is expecting a value here (instead of None) and therefore throws an error. Maybe there's a better way to approach this.

Right now, the league-edit.html template seems a little cluttered and not totally intuitive. Could add instructions at the top (like for the Season section), and enhance the selections to preselect the current values.

I'm already getting current value, but it is not always preselected in the options.

Or, the preselection as the 1st option looks a little odd: