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.
This starts using webassets for the site-icons.css file inside the base
template so that a cache-busting "version" string is added after the
filename as a query variable (as was already being done with the other
CSS and JS files).
It also creates a new service that's triggered by a "path changed" event
on site-icons.css, which causes gunicorn to reload. This should mean
that whenever the site-icons.css file is updated by the cronjob that
generates it, gunicorn will automatically reload and update the
cache-busting string for the CSS file, causing users' browsers to update
to the newest version.
The new version of Salt ("3000") seems to have a number of bugs,
including not being able to handle "unless" checks, which the Tildes
states use frequently. Because of this, creating a new dev environment
currently doesn't work. This pins Salt to the previous stable version
for now.
Here's the relevant bug for "unless" specifically:
https://github.com/saltstack/salt/issues/56131
And the overall release notes:
https://docs.saltstack.com/en/latest/topics/releases/3000.html
Deimos
Shahzaib Sahibzada
dougmellon
Timo
Bauke