Add the ability to override eligibility for Yuletide fics
antialiasis opened this issue · 0 comments
Could also apply to e.g. fics entered in a one-shot contest that don't get threads until after the beginning of the next year. Basically, we want to be able to tell the system that some fics that weren't actually posted until after the end of the awards year are still eligible. This should make them automatically ineligible for any later awards, too.
We could do this with shenanigans involving manipulating posted dates. This has the advantage of working without any new infrastructure to support it... just barely; we'd either need to be able to do a lookup without validating them or manually create the Fic objects in the admin in order to have a post date to manipulate in the first place. Presumably then the post date would be set to Yuletide reveal day. However, this is a bit hackish, and could cause problems if we ever for any reason refetch the fic and its posted date (which would mean we need additional infrastructure anyway).
It would also be possible to simply manually add these fics to the eligibility cache. This is also a bit hackish, but technically the eligibility cache isn't even called a cache in the code, so who is to say we can't just add entries to it? This is pretty convenient; we would need to add two entries for each late-posted Yuletide fic (one to make it eligible for this year, one to make it ineligible for the next), but would need absolutely no additional infrastructure other than adding an admin interface to edit FicEligibility objects, and even has room for the possibility that a Yuletide fic could grow into a chapterfic that should be eligible for the next awards (all we'd need to do is remove the entry that says it's ineligible for next year). The error message when someone would try to nominate one of them next year would be a bit misleading, since it would only reference when the fic is posted or updated, but this may be uncommon enough to not really be a problem. It's also not super-convenient for admins to do, but this is an exceptional case, and on that front it has the advantage of not requiring the Fic objects to be created in the database first.
The third option would be to add some actual special infrastructure, but after typing all this, that option is looking less attractive by the minute. It would mean a better admin interface, and a better error message, but also an annoying increase in complexity. Yeah, no, let's just go with option two.