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
If a user can edit a post, they don't need the ability to view the
markdown separately, so the button doesn't need to be shown in those
cases. I'm not sure if this should be a separate permission defined
inside the ACL or not.
The "roadmap" issue boards on GitLab aren't being maintained in any sort
of useful way, and are probably just more confusing to anyone than
helpful. This replaces that link with a "Planned Features" one that goes
to an issue search for ones that have both the "Stage::Accepted" and
"Feature Request" labels, sorted by GitLab's "priority" method which
will put High Priority ones at the top.
I removed this no_autoflush block in another recent change, but it was
still necessary due to the calls to _mark_comment_read_from_interaction
not being inside the try: block looking for an IntegrityError. This
could also be done in a different order to avoid the issue without
needing to disable autoflush, but this works fine.
This should prevent a few strange behaviors related to topic visits,
such as "losing" new comments if you accidentally double-click when
entering a topic's comments.
Currently, the "grace period" is set to 2 minutes, and no new visits
will be stored until the previous visit is at least that old.
This changes from storing only a single topic visit per user to just
storing all of them. I don't intend to keep all of these and will
probably find a way to "quantize" repeated visits soon. However, I want
to get an idea of the volume first, and also use this to see how the new
querying methods work in production.
On that note, I'm not sure that the LATERAL outer join is the best
method, but it seems interesting (and was kind of a pain in the ass in
SQLAlchemy), so we'll see how it looks.
As part of this, I also changed the method of adjusting num_comments on
past topic visits to be done entirely in triggers, instead of the
previous approach of doing it in _increment_topic_comments_seen().
However, this really just made me realize how incorrect this idea is and
how many edge cases can come up that will mess up the comment counters
on the visits (e.g. post a comment and then delete it immediately).
Hopefully this can go away in the somewhat near future with some other
changes to notifications.
Deimos
Bauke
Alexander Bliskovsky
Cassidy Dingenskirchen