Previously a topic with an unknown content type would display "Article".
This switches to "Link" which will have some different idiosyncracies,
but should be a little more correct in general.
When a chain of comments has been fully removed, this will display a
single marker like "Removed by admin: 8 comments by 2 users" instead of
individual "Comment removed by site admin" markers for each one.
This should be stored in the database so that we can take advantage of
it for searching/filtering, but I want to test it on the live site first
and get input about what other types of content get posted. It'll be
simpler to leave it in code only for that, and I can add it to the
database later.
I've always been pretty unhappy with the ugly way tags were implemented,
using @hybrid_property and needing to do strange things all over the
place to deal with converting underscores to spaces and vice versa, as
well as other idiosyncracies.
There are still a few oddities here and there, but overall this is much
better.
Now that there are topics being posted automatically by the "fake" user,
we don't want to be generating reply notifications for that user
whenever someone posts a comment in them. These serve no purpose and
would just pile up forever without being read. The same problem could
have already been happening if people replied back to a comment with the
"unknown user" author.
This was always inconsistent - I've been setting objects in some models,
and ids in other ones. Using ids can cause various errors, especially in
cases where one of the objects involved hasn't been committed to the
database yet and so hasn't been assigned its id.
For some reason (maybe only in the default/white theme), this was using
currentColor, making the "indentation" borders darker than they should
have been.
Renames the username_linked macro to link_to_user and takes a User
object instead of a username, so that we can handle more than just the
"unknown user", including the new generic "Tildes" user.
This adds the backend for scheduled topics, which can be set up to post
at a certain time and then (optionally) repeat on a schedule.
Currently, these topics must be text topics, and can have their title,
markdown, and tags set up. They can be configured to be posted by a
particular user, but if no user is chosen they will be posted by a
(newly added) generic user named "Tildes" that is intended to be used
for "owning" automatic actions like this.
Topic tags are no longer shown in listing pages by default (except
"important" ones such as "nsfw" and "spoiler"), and the layout and
emphasis on them has been adjusted in multiple other ways as well. A
preference to continue showing them in listings has been added, and this
preference is enabled by default for all users with the "topic.tag"
permission (ability to tag any users' topics).
Other changes:
* The tagging field is collapsed by default when posting a new topic. If
a user expands it and enters tags, it will be shown expanded in the
future. It will also be expanded by default after the user
adds/changes tags on a topic, and will also be set automatically for
users that have shown an interest in tagging recently (by submitting a
topic with tags or changing tags).
* "Content metadata" such as word count and duration is now shown next
to the group name (where tags were previously), instead of after the
title.
* Topic icons (favicons) are now shown next to the domain name, instead
of before the title. Blank icons no longer have a dashed border and
are now just an empty space.
* When on a topic's comments page, tags are now shown in the main
content area, below the "byline" information about who posted the
topic and when, instead of in the sidebar.
* Other minor layout changes to adjust for tags, as well as prepare for
some other upcoming changes like adding "actions" to topics in
listings.
We don't want inline code to increase the line-height of lines its in,
since that makes paragraphs have uneven line-heights and looks a little
strange.
There are some new capabilities in mypy 0.730, including nicer output
formatting, which this enables. I'd also like to be able to use the
specific error-code ignoring instead of the current all-encompassing
"type: ignore" comments, but there's currently an issue with that:
https://github.com/python/mypy/issues/7562
This uses Stripe's Subscriptions capability to set up recurring
donations. Requires setting up a Product for the recurring donation, and
defining its product ID in the INI file.
This seems to be a separate Semrush bot that doesn't listen to
robots.txt for the main SemrushBot UA. Their site also says to block
"SemrushBot-SA" and doesn't mention "-BA", but I don't know if that's a
mistake on their end or if this won't work.
Alembic 1.2.0 adds the ability to post-process revision scripts, so this
uses that capability to automatically run any new files through Black.
This always had to be done manually before, so it's nice to have it
taken care of automatically like this.
Version 1.5.1 of pyramid-session-redis has a change to how session IDs
are generated that will cause all existing sessions to be invalidated.
Before upgrading it would be best to set up some migration to be able to
keep the existing sessions, so that everyone doesn't need to log back
in.
There's some info in pyramid-session-redis's CHANGES file:
https://github.com/jvanasco/pyramid_session_redis/blob/master/CHANGES.md
Apparently add_header inside a location block doesn't... you know,
actually work. This should be reasonable, but I'd still rather only
allow the Stripe JS on the single page where it's necessary.
The issues that were causing prospector to break have been fixed, so
this is safe to un-pin now. Required a few config changes and code
updates to fix some new errors that came with the updated versions.
Previously I was just using Jinja's built-in loop.depth0 to output
comment depth in HTML, but actually attaching a depth attribute to the
comments will allow it to be used elsewhere as well. It's possible this
should even be on the Comment model itself, since it never changes and
might be useful in other ways.
The post buttons (Reply, Delete, etc.) were converted to <button> quite
a while ago, and these ones should be switched over for the same reasons
as those were (accessibility, more semantic), as well as being able to
support the error messages from Intercooler.
Deimos
Jason Schwarzenberger