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.
This allows all users to edit their own topics' titles for 5 minutes
after posting, to be able to fix typos or other issues. Admins and
people with the specifically-granted permission can still edit titles
regardless of the topic's age.
Previously, error messages were only shown inside <form> elements. If a
button hit an error (such as a 403 when trying to vote on a comment that
was deleted after page load), the button simply wouldn't work with no
indication of why.
This adds the error message into the <menu> containing the buttons, and
involved some reworking of the relevant JS and CSS.
Since we're adding a prefix to the Solarized theme's "value" and CSS
class, we need to convert old values so that people using a Solarized
theme don't lose their setting. This changes it in two places:
* The value of the "theme" cookie, using the tween we already have for
dealing with that cookie.
* The user's default theme setting in the database.
Since the site originally launched with only the Solarized themes,
they've always just been referred to internally as "light" and "dark".
This changes them to solarized-light and solarized-dark respectively.
Previously, the "theme cookie tween" was setting the theme cookie on
every single GET request, in order to make sure that the domain was set
on it so that it would be accessible from the Blog and Docs sites. We've
been doing this for a long time now though, and almost every cookie
should have been set properly now.
Now, this tween will only set the cookie when it's actually necessary -
when the user is logged-in and has a default theme, but doesn't already
have a theme cookie.
Deimos
Jason Schwarzenberger
Lugubris