joekennedy/fantasy

A Fantasy League Of Ice And Fire

fantasy's Issues

Allow more than one league member to manage the league

Related to #3. Allow more than one person to manage the league. Presumably they'd be a team owner, but if the given issue (#3) is implement then in theory they wouldn't have to be a team owner.

API-iffy the repo

This would let other people build mobile apps, React apps, etc. since the site is open source. It could also be helpful for people who wanted to do data analytics on the database.

Turn Finalize Events into a background job

This way it won't hang forever, as it currently does. Related to #6, since it would be a change to the similar parts of the code. It would probably be a good idea to do these around the same time.

Allow multiple people to own a team

This is super low priority and no one has even requested it, but I figured I'd add it because it would likely be a nice to have for next year if a lot more people are using the site.

Clean up and improve isAuthorized in Foundation.hs

Incremental improvements to this function will come with moving to an admin interface (issue #23) and making team and player links unique within the league (issue #1), but the function will need a number of improvements in addition to these. Namely:

• Ensure all routes can be accessed if and only if the necessary conditions for access are satisfied
• Each require... function that requires the user be logged in should probably do that first, just to be safe.

These are the main high level improvements I can think of; if I think of any more I'll add them here.

Create week data when the associated episode is created

This will have a few potential benefits:

1. airEpisode will only be necessary for marking an episode "Airing"; when determining the current week, just use the air date of the episode, rather than grabbing the most recent week. There could probably be some helper functions here, like getCurrentEpisode and getCurrentWeek.
2. I can create the episodes whenever, because I wouldn't have to worry about them being created after a certain time.
3. We can grab the current performance for each player to accurately show their current cumulative points, i.e. the points they've scored in the last (for this season) seven scored weeks. This might help further explain the weighted points system, and plus, more numbers!
4. Lineups no longer need to be sealed by airEpisode running and functioning properly, just use getCurrentWeek to determine which week to use for starting, benching, claiming, etc. players.

Allow Claims to be reordered before processing

Right now, claims are processed for a team in the order they're submitted, and once they're entered, they can't be ordered or re-entered. Two potential solutions for this:

1. Easy solution: Just let them be deletable, and have the user re-submit the claims. Great for us, sucks for them.
2. Harder solution: Implement a UI to allow reordering them. No sure what a good UI would be for this. Ideally the user would also be able to delete any claims they made as well.

Create Profile page for user

Users should have a page to manage all their leagues, teams, messages, etc. from. I think the profile page should have:

• List of leagues user belongs to and the teams they own in each league
• List of leagues that user is the commissioner of
• A message center to aggregate messages for all leagues they're in
• Profile information, i.e. email address, name, etc. (to be used for defaults when joining or making a new league)
• Ability to add other oauth idents, to link (say) Facebook profile and Gmail account to same user to enable log in with either
• Reach: Ability to combine users, if say they have one team under their Facebook and another under their Gmail accidentally.

The question would be if each user should only be able their own profile, or if more people should be able to see it. There could probably be varying levels of privacy, i.e.

• Private (only you can see it)
• "Friends" only (those who are in leagues with you)
• "Friends of friends" only (those in leagues with you, or leagues with your "friends")
• Logged in users only
• Public (anyone can see it)

Probably to start making it private would be fine, since it's not really meant for social networking or whatever; it's more made for users with multiple leagues who want to be able to manage them more easily.

Trade Deadline!

The trade deadline needs to be implemented.

Add an offset and/or pagination to admin index pages

This will help with load times for Events and Blurbs especially. See Persistent's OffsetBy for more information.

Allow Admins to see private leagues

This would help with debugging any issues that users in private leagues have discovered. Last year this happened a few times, and I either asked the Lord Commander of that league to make it public temporarily, or I copied the database to my computer and changed the league to public there. Neither are ideal; hence the creation of this issue.

Add scoring progress alert to top of league layout

Rather than figure out (and pay extra for) emailing and all that jazz, I think it'd be easiest and the least amount of work to add a permanent alert to the league layout that says how far along in scoring we are. It'd have the following statuses:

1. Episode (list episode name in the alert) is airing, and lineups for week X are locked in.
2. Episode has aired but scoring hasn't started.
3. Scoring for episode is in progress
4. Scoring is complete; leave this up for maybe 24-48 hours, maybe say when it was completed

I'll see if I can get this done before episode 1 of season 7 airs. No promises!

Email Sending: Admins should be able to message all league commissioners

This would likely be put under "Score" in the Admin interface. Admins should be able to list all league commissioners (by email addresses, to start) as well.

Store email for each user

The application is already capable of storing emails on the database level.

For existing users, we can grab it from one of their teams.

For new users, we probably want to first grab the email from the OAuth login if we can. Otherwise, if they are signing up to join a team, we can grab it straight from the team. However, if they're creating a league, we won't be able to grab it automatically. So we could make a form for email and put it in somewhere in the league setup process

Allow the user who suggests a trade to cancel it

If a team owner accidentally choose the wrong player for a trade, they should be able to cancel the trade before it's accepted (or canceled) by the team owner to whom the trade was proposed.

Allow X for Y Player Trading

Right now, you can only do 1 for 1 trades. It would be good to allow 2 for 1, 3 for 2, 2 for 2, etc.

Add a README

This should probably be done at some point, just to give an overview to anyone who wants to look at the code but doesn't know the best place to start.

Determine which environmental variables should be optional

Since I've discovered environmental variables can be optional in settings.yml, I should move all variables currently listed here into settings.yml, and see which ones I can make optional. Definitely the let's encrypt ones, probably the Google and Facebook ones, and potentially the Amazon ones. Other than the Let's Encrypt ones, these would all still be (essentially) required in production, but shouldn't be necessary for development purposes.

Email Sending: Email users when scores are posted

Related issue: #2 could be completed first.

Once scores are posted for the week, find all users in at least one active, setup complete league, and send them an email.

Add Blog to the site

Currently the Blog nav links to https://smigoversensays.com/game-of-thrones-fantasy/, which is fine for the time being. But it would be nice for the blog to be integrated into the site.

Allow entities to have images

At the very least, characters should have images to help users who aren't die hard nerds or who don't feel like googling names they don't recognize. The latter keeps people on the site!

Further things that could have images, in order of importance:

• House
• League
• Team
• User

Make a React native app

The code for this will probably end up in another repo, but it would be helpful to have updates on this issue, especially if anything in this repo needs to change.

Job Queue: move changeEventsRelations to a queued background job

This essentially has two parts:

1. Set up and configure the yesod-worker library to work with this repo.
2. Create a changeEventRelations job that is added to the queue each time the event core changes.

This will be the first queued job; others will probably come up down the line, hence the enhancement tag. But this will also help to address (though in theory, not actually fix) the fact that the slow AJAX return when editing on the score page has created duplicate events, one with no note and the second one with a note.

I should probably fix the fact that duplicate events would still be possible even with the implementation of this feature, but I'll see how week 2 scoring goes first. If it's a non-issue, great! If not, the solution might be to generate a UUID on the client side and send that to the server, rather than needing the new event id to be returned by the server to the client before another AJAX call can happen successfully.

I should note that in the beginning I started working on the scoring page with the UUID implementation but gave up on it. I think I gave the current solution a "good enough" stamp and went about my business.

There could be another solution as well that stays entirely on the client side. One way I can think of would be to essentially queue up somehow any requests made for events that have already been created but haven't yet gotten back an ID from the server. I'm not sure how feasible/easy this would be, and it might take a level of JS-fu that I'm not currently at.

Speed up deleting on score page

Right now when deleting an event on the score page, a delete is triggered and then the page is reloaded. Since page reload takes awhile, it'd probably be better to just remove the row rather than trying to reload the page. I should also maybe disable the "delete" button so that it's not double clicked at all.

Email Sending: Successful league creation

Related issue: #2 (should probably be completed first)

When a user completes the setup for a new league and emails are sent to the league members to join, they should also receive an email saying that they've successfully created a league.

Process player claims using team waiver order

I realized at the end of last season that player claims weren't actually being processed using the waiver order of the teams. This should probably be corrected before next season.

End of season clean up

Certain things will need to be implemented to ensure the season ends correctly. The only necessary thing I can think of at the moment is that player transactions should be disabled and all requested transactions canceled.

I'm sure there are other things that need to be done, but as of right now I can't think of anything. There should probably also be a separate issue for things that need to eventually be done, but aren't necessary before the season ends, and then another one entirely (or multiple issues likely) for things that need to be done in preparation for next season.

Parse sslmode and sslcert as part of database parsing in settings

I've implemented the quick and easy, which doesn't look pretty. The way it should be implemented is as part of the DATABASE_URL parameter that is used by Heroku, so the database configuration can be changed with one variable, rather than six as of now.

Try to switch from Halcyon to Stack

I've always wanted to use Stack for package management of this project, but when I started this app I couldn't seem to find a good Stack buildpack, so I went with Haskell on Heroku, which uses Halcyon. I think(?) I've found a Stack buildpack for Heroku: Heroku Buildpack Stack. More info on how to use it here.

Create League! button should redirect user to most recent completed step of league setup

This is to avoid confusion for people who have started making a league but haven't completed it yet, and decide later to make a new league. In this case they might think the league name is a placeholder, remove it, and then be surprised to discover that they can't actually change the number of leagues.

I'm thinking of having a route leagues/setup/new that routes to the correct step, and changing the existing new step to be leagues/setup/start, since it's the start of the setup. This is a low priority issue, but I wanted to add it while I remembered it.

Move FAQ into a database table

This will make it easy to edit any of the entries, and also to change the look of the page, which right now would be a pain in the neck.

Turn Teams table on teams page into a bootstrap-table

This will allow the user to sort by waiver order, draft order, etc. In addition, the teams are currently sorted last place first. That should probably change.

Allow the league manager to resend join emails

Right now, if someone enters the wrong email address or mixes up the teams (see issue #3), then someone may not get an email. The league manager should be able to send the join emails again for this purposes. There should probably be something put in place to prevent the league manager from resending the emails a bunch of times. Maybe add a timestamp to the league table for when the join email was last resent, and wait 24 hours or so for resending.

There's also the question of resending to individual team owners or just resend to everyone who hasn't already joined. I'm not sure which is better. I'm leaning towards the former, because it's rare that you'd need to resend the email to more than one person at a time.

Don't allow user to join league twice

This came up when one user somehow became the owner of two teams. I'm guessing what happened was that he made the league and made his team the last team. So he was made the owner of the first team (because the system automatically does that at the moment) and then he joined with his team, so he was made the owner of that one as well.

Fixing issue #3 should alleviate that specific case, but it doesn't prevent a user from accidentally joining the league using the link .

I can't use a unique constraint for this at the moment, because teamOwnerId is currently a Maybe UserId and Yesod doesn't allow unique constraints for nullable fields. This would probably come for free with implementing issue #15, since team owner would likely be a separate table, a constraint like UniqueTeamOwnerLeagueIdUserId would suffice.

However, a request should probably check if there's an entry for the leagueId userId pair and render an alert that says something like "this person already owns a team in the league", rather than just spitting out a unique constraint error.

Copy event on Score Episode page sometimes duplicates the wrong row

I can't get a 100% accurate reproduction route for this issue, but occasionally when clicking the "Copy Event" button for an event row when scoring an episode, that row isn't actually duplicated; another row is. This is more of a nuisance than anything else.

Add a UUID to Event

As I detailed a bit in #40, there's a bug creating duplicate events on the score page. This is because, right now, when a new event is added, it's submitted to the server and then created, and the resulting id is returned to the client. This id is then added as the value to the id field of that row. However, if a field in a row is changed before the id is returned, the interface will submit this as a separate event, hence creating a duplicate.

To get around this, I'll add a UUID field to Event. This can be generated as a unique value for each existing event; I believe this is something that's possible in Postgres. For new events on the score page, I'll need to add a value to this field as soon as the row is added, either with the Add More Events button or by copying another row. For new events on the event form, I'll need to generate this when generating the event form.

Don't require league manager to be the first team in league

Also don't require the league manager to own any team in the league.

This could probably take a few forms. The easiest way would likely be to send out join emails to all members of the league, rather than all but the first. The issue with this is that if the league manager is in the league, they actually have to join it, rather than just being in it automatically.

Probably the way to go would be to grab the email for the user, in #2. And if it matches one of the team owner emails, mark that team as joined and add the league manager as the team owner. Otherwise, send out the join email to team owner's email address.

Revamp the home page

Should probably have news on it (i.e. recent blog posts and player blurbs), among other things. More details to follow.

Playoffs!

Playoffs need to be implemented

Email Sending: League Manager should be able to message all league members from the site

Easy (and cheaper) way, pop a mailto for all members.

Hard way, send an email through the site. Well actually, it's probably not that much harder, but it would require a form, rather than just a link.

Move parts of league creation into a background job

Some of the things that happen as part of league creation are probably not necessary to run right away. Creating the week-related information can probably be pushed into the background, since it's not necessary for setting up the league. In fact, anything that's not necessary for league setup should be moved into a forked background job.

Make team and player URLs unique within league

The TODO is here: https://github.com/JoeKennedy/fantasy/blob/master/Foundation.hs#L125

Two options here:

1. For player routes, use characterId instead of playerId and for team routes, use (and, first, add) teamNumber for team routes instead of teamId.
2. In inAuthorized for team and player routes, require that the teamId and playerId, respectively, are in the league.

I'd prefer the first option, because it'll shorten the urls for each, so it'll produce /leagues/50/players/110 instead of /leagues/50/players/2345. However, you'll have to change all the routes to take the new parameter, and lookup the relevant entities using getBy404 rather than get404.

Move Actions into a database table

Not sure if this is the best way to go about it or not, and I'd like input from someone else before deciding whether or not to go forward with it. It would certainly make certain things easier though, like adding or removing actions, or the changing default scoring, since it won't take a code change to do those things.

Columns would be (names could be improved):

• Name
• IsMultiCharacter
• SplitStringPre
• SplitStringPost
• ReverseString
• DefaultIsUsed
• DefaultPoints
• DefaultWeight
• DefaultPointsReceiving
• DefaultWeightReceiving

Set lineups after the draft has been completed

Right now, when the draft results are entered and the draft picks are added to their teams, every player is added to the bench. The system should add the first x draft picks as starters, where x is the allowed number of starters for the league. This would be helpful if a league did the draft the day of an episode airing, because then if players weren't able to start their players, their line up would be set by default.

Speed up loading of score page

Right now the score page times out for the most recent episode (Beyond The Wall). This essentially defeats the whole purpose of the score page. I need figure out a way to make this page load much faster. I imagine some improvements to be had could be:

1. On page load, only load the selected option for the dropdowns. Then, in JS, add all the possible options to each dropdown.
2. Load only the first X events on page load, then load the rest on scroll down or alternatively on document ready.
3. Change some of the dropdown fields (specifically the character ones, though the action field might be good to change as well) to search fields, where every time a char is typed into the box, an AJAX call is made to the server to find all the characters whose names match the currently value of the field.

I'm sure there are other ways to improve load time (and I'll certainly add them if I think of any more), but this should be a good start.

Redirect all traffic to https

I keep looking up how to do this but all the solutions I've been able to find seem like they'd be a whole thing given that I don't feel like doing this myself. I'd mark this as an enhancement if it didn't affect the UI, but right now it won't load the local stylesheets and javascript files properly unless you're on https, so any Font Awesome icons will render as a square on all the pages.

Email Sending: Reminder to set lineup

This might need to be configurable, like under General Settings, for whether or not send it, and how soon before the episode to send it.

Add an admin interface for inserting the site-wide data

This includes:

• Characters
• Species
• Houses
• Series
• Episodes
• Events
• Blurbs

It could also include Actions and FAQ if they're moved into the database, and Blog posts once they're added. This would help in managing all these entities, and would simplify the user-facing views. Not if/then logic for whether or not to display forms.

If an admin plugin/library exists (though a preliminary search a few months ago did not produce one), we could probably use that, or we could write our own. However, just implementing an admin interface for our site, rather than writing a whole library and using that, would be fine.

In the future, it might be good to add all tables, including all the league-specific ones, to the admin interface, to prevent someone (usually me) from having to go into the DB to make minor changes, which is never a great idea, but right now is necessary in a lot of cases. But for this issue an admin interface for the tables/entities listed above is fine.