By default, new top-level comments will only be allowed in the latest
topic from a particular set of scheduled topics. Replies to existing
comments in old topics will still be allowed - this is just intended to
prevent the cases where an old scheduled topic gets bumped back up due
to a reply and people inadvertently start adding new top-level comments
to it instead of the latest one.
This should be the correct behavior for most scheduled topics, but it
can be disabled for a particular schedule if needed.
This adds a new latest_topic_id column to topic_schedule and uses
triggers on the topics table to keep it correct.
This isn't really ideal, but it will simplify a few things related to
scheduled topics by quite a bit. For example, this commit also uses that
new data to much more easily populate the list of scheduled topics in a
group's sidebar, which previously required a subquery and windowing.
I think overall this is triggering more than I want, and getting in the
way of perfectly reasonable conversations. I like the idea still, but
needs adjusting.
Coronavirus topics have slowed down greatly now, with generally only
about 3 per day, and are almost all restricted to ~health.coronavirus,
so users can easily find (or avoid) them by just using that group.
Previously, the comment reply form was being created entirely
client-side by cloning and modifying a <template>. This was nice because
it meant that a network request wasn't necessary to display the form,
but it also had downsides.
For example, if a topic was locked after a user had already loaded the
page (or their notifications page with a comment from that topic), they
would still be able to click Reply and type in a comment, and wouldn't
know that replying wasn't possible until they actually tried to submit
the comment.
By switching to using intercooler for this form, we can do server-side
validation to check permissions before showing the form, and it also
simplifies some other aspects, such as the warning about replying to an
old comment, which previously needed a data-js-old-warning-age attribute
in the HTML, but is now just part of generating the reply form template
server-side.
If a comment is removed and then deleted by its author, we should
continue showing it as removed, since that's the more significant action
(and the deletion is usually *because* of the removal).
This will probably only ever be relevant in development environments,
but we don't want the topic scheduler to always post a full backlog of
scheduled topics when it hasn't run for a while. For example, if a dev
environment has a daily scheduled topic set up, but the VM is not
launched for a week, the next time the "post scheduled topics" cronjob
runs, it will post all 7 of the backlogged topics.
This commit changes the script so that it advances the schedule to the
next *future* occurrence, instead of continuing the backlog.
Previously, TopicQuery was excluding ignored topics by default. However,
this caused some unexpected issues, such as a crash when someone tried
to vote on a topic after ignoring it. I think it's more intuitive to
reverse the logic like this: include the ignored topics by default, and
only specifically exclude them in the cases where that's necessary.
This adds some very simple metrics to all of the background jobs that
consume the event streams. Currently, the only "real" metric is a
counter tracking how many messages have been processed by that consumer,
but a lot of the value will come from being able to utilize the
automatic "up" metric provided by Prometheus to monitor and make sure
that all of the jobs are running.
I decided to use ports starting from 25010 for these jobs - this is
completely arbitrary, it's just a fairly large range of unassigned
ports, so shouldn't conflict with anything.
I'm not a fan of how much hard-coding is involved here for the different
ports and jobs in the Prometheus config, but it's also not a big deal.
This enables me to set a ban expiry time for a user (manually, in the
database). By doing so:
* The user's page will say that they're temporarily banned, and show the
date their ban will be lifted.
* If the user tries to log in, it will say they're temporarily banned,
and give a specific datetime that the ban will be lifted by.
* An hourly cronjob will lift any bans that have expired.
I get a fair number of "forgot password" emails where the person is
actually trying to log in with the wrong username. Normally, a login
system shouldn't display whether the username or password was the
incorrect part, but since it's already public information which
usernames exist on Tildes (simply by visiting /user/<username>), this
really isn't meaningfully hiding anything. It would only have any effect
on the most absolutely naive attackers. I think it's an acceptable
trade-off to help out people that are inadvertently trying to log in
with the wrong username instead.
Adding the info about the coronavirus views overrode this block, so we
can just show either (or both, which probably shouldn't happen, but
could) by doing this.
This is a prometheus exporter that allows checking IPv4 and IPv6
responses, among other things. This sets it up to make sure that the
site is responding over both IPv4 and IPv6, so that I can monitor and
set up an alert if either stops working.
This probably isn't particularly safe, but it's fine since I'm the only
one that can create or edit scheduled topics for now. The only available
variable so far is current_time_utc.
This is kind of hacky again (and shouldn't contain the coronavirus tag
over the long term), but makes sure that the "spoiler", "nsfw", and
"coronaviruses.covid19" tags are always offered as autocomplete options,
no matter how common they are in the topic's group.
This adds two links at the top of the home page that go to different
"views" - one includes only topics related to the coronavirus, while the
other filters out all coronavirus topics.
For the purposes of these views, a "coronavirus topic" is one that is
either in the ~health.coronavirus group, or has coronaviruses.covid19
tag.
This is very hacky and will only work on the main tildes.net site due to
hardcoded group name and tag. I'm okay with that.
This replaces the groups page with a new list style that doesn't include
the ability to subscribe/unsubscribe directly on the page, and also
shows approximate activity statistics (daily topics/comments) for each
group.
Let's try this again without the regex.
Clicking the X button in an autocomplete chip could inadvertently remove
the wrong tag (and cause a weird "merging" behavior) if another tag
ended with the same text as the one being removed. For example, if a
post had both "one.two" and "two" tags and you clicked the X button on
the "two".
Clicking the X button in an autocomplete chip could inadvertently remove
the wrong tag (and cause a weird "merging" behavior) if another tag
ended with the same text as the one being removed. For example, if a
post had both "one.two" and "two" tags and you clicked the X button on
the "two".
Just a couple relatively minor updates to the financial stuff:
* Removed the "is_approximate" column on the table and just added a more
general note about most of the amounts being approximate. It was more
annoying to worry about than meaningful.
* Some style/layout/wording tweaks to the donation goal to try to make
it a little more obvious that this is a long-term sustainability goal.
This is a major rework of the permissions system to enable various new
capabilities and clean up some of the oddities that were there.
Highlights:
- The concept of "admin" permission is removed. All permissions must be
granted individually.
- Permissions can now be granted on a group-specific level, such as
giving a user the ability to tag topics only in a specific group.
- Permissions can also be denied for a specific group (or all groups),
enabling uses like "tag topics in all groups except ~music".
- Removed the two cases where "all permissions" were granted: users on
themselves and the sender and recipient on messages. This was
dangerous, we should always grant permissions explicitly.
- Eliminated all the granular permissions for changing a user's settings
(which were all granted implicitly), and replaced with an overall
"change_settings" permission.
This is a bit of an odd commit: it adds a user_permissions table that
has capabilities that are not yet usable. Specifically, the table allows
setting DENY permissions as well as restricting permissions to an
individual group, but neither of those work yet. I want to make sure
that the existing, limited permission system seems to transfer over
properly before adding the additional complexity for those.
The Alembic data migrations for this commit is fairly ugly, but seem to
work okay.
Note that this will also prevent a title from ending with "...". I did a
search for all titles that ended in that, and none of them seemed
essential (and probably should have been removed), so I think this
should be fine.
