transaction behaviors

[jeremyjbowers]

@baldrige is documenting the business logic; transactions already exist as models, now we just need to use signals and post-save hooks to do as much work as possible for each of the transaction types.

[jeremyjbowers]

blocked pending business logic but can probably mock up a few things like:

• [ ] approvals via email or text
• [ ] trades? (though these are complicated by things like picks, future / cash considerations, IFA $)
• [ ] nontender should be easy
• [ ] signing a free agent should be relatively easy
• [ ] signing an IFA should be relatively easy
• [ ] waiver should be easy

[matthewyaspan]

Going to start with IFA signing which I think will be most straightforward.

Was thinking about waivers and through a few design choices.

Things we definitely want:

• A page representing the waiver wire. Waivers are weekly and expire at Friday 1pm eastern, and there are two types, outright and Rule 5.
• The page should be populated by this player_row.html object much like it currently is in the google sheet.
• You can only outright a player currently on the 40, and only Rule 5 waive players who have been Rule 5 selected that year and are not on their original team.
• Teams need a waiver priority

Design choices I'm not as sure about: The easiest mechanics I can think of are having the icon currently on the 40-man column on a player row in a team page become a button that yields a dropdown with options like "Outright," "Rule 5 Waiver" and "Release." This would set a flag on the player model that they are currently on outright waivers or Rule 5 waivers or released. There could then be a "Submit" button on the team page that submits a form with these data for processing. Submission would set the waiver flags for players and also remove them from the team page. One thing I'm curious about is the. We can then populate the waiver wire page with Django filters on all the players looking for outright/rule 5 flags.

In order to make a claim, I'm not sure if it would be simpler to just add logic to the 40-man icon in player_row that makes it context dependent as to whether the players is on. waivers or not where the 40-man icon isjust have a slightly different "waiver_player_row.html" for rendering that is mostly the same but has a different column to indicate a waiver claim form.

At waiver processing time, We can have some offline cron job/some thread in the service (not sure how Django does these things) unsetting their waiver flag and either processing the claims by waiver priority, or outrighting/offering the Rule 5 player for return as necessary.