still todo migration
"ips" will make more sense for staff now
qrange/hrange no longer need to be stored
bypass still work like before. will have .BP suffix, normal ips are .IP
filtering and stuff still works
bans page will now show .*'s in the cloaked view for range bans
in future version, this allows (even for those who cant see raw ips):
- modlog, bans, post hisory filters including per-range
- directly input ips/range cloak to ban, without selecting a post
- upgrading existing bans from single to ranges
They were getting reset to their latest reply date, when a bumplocked thread should never have its
bump date reset to earlier than whatever the latest reply was when it was bumplocked, or the OP date
if all replies are deleted.
Still not accounting for bump limited thread (a uncommon edge case), and i think the simplest way to deal with that would
be set bumplocked:1 when its exceeded the board settings bump limit. More efficient, less work for me, and actually
serves a useful purpose because long threads could tell when they are bumplocked from going past bump limit.
The only decision then would be whether to set it permanently from that point forward, or only set it once,
so they could be unlocked by moderators if they want which would be an added side effect/feature of being able
to selectively unlock them.
wtf is this commit message, and the code for this section is a cluster fuck lmao
Previously early404 would match the threads with less than "early404Replies" BEFORE skipping and then deleting.
Which would be incorrect because then early404 would only be deleting a fraction of the posts with less than
early404Replies, rather than any thread with less than early404Replies past a certain fraction of the threadLimit
Bit of a stupid mistake, but this should fix it, if my interpretation of how early404 is supposed to work is correct.
This prevents prolems like `/` giving 404 in devel mode (when
`static/html/index.html` is missing) or `/captcha` redirecting to
`/captcha/` (then breaking).
some random guy