Embedded local posts (posts which link to posts on the same site)
embed the linked post using submission_listing.html via
helpers/jinja2:post_embed. This suffered from much the same issue
recently fixed in submission.html through the addition of
`v_forbid_deleted` in the template before outputting privileged
information. A similar fix has been applied to submission_listing.
Unfortunately, this is not the most elegant fix. Surely this would be
better resolved more centrally in the submission model. However, I am
not clear at present about the precise interaction between deletion,
removal, and realbody & realurl in all of the different places they
are used. This commit fixes the problem, but it also highlights a
potential future refactoring target.
In light of the fact that all searching against the database is done
using ILIKE pattern matching, the only truly case-sensitive part of
the search query was search operator keys. Rather than lowercase the
keys in `criteria` before returning, we instead lowercase the entire
search string at the beginning of parsing. This will further enforce
case-insensitivity on the design of search going forward.
Previously, Markdown ordered lists in user content (in posts,
comments, previews, etc) would display like this:
1.
Foo bar baz.
This is because sanitize populates them as <li><p>Foo bar baz.</p></li>
Rather than mess with the Markdown engine and still not have backwards
compatibility, this has been solved in the frontend using CSS to force
the <p> to display inline.
Draft posts have already been excluded from the edit time limit for
obvious reasons--drafts are intended to be edited, and people use them
as personal megathreads on their profiles. Largely for the latter
use case, this commit also excludes comments on drafts from the limit.
Previously, cli.py ran in <repo-root>/files. However, our relative
paths assume the working directory is <repo-root>. This resulted in
sanitize.render_emoji L153 to improperly return false when checking
for the presence of 'files/assets/images/emojis/{emoji}.webp',
leading to emojis in notifications sent by cli.py-invoked tasks to
not be rendered to HTML.
This bug was discovered when lottery.check_if_end_lottery_task was
failing due to a stack trace thru end_lottery session < badge_grant
< send_repeatable_notifications < sanitize L208. In particular, when
`flask cron` (helpers/cron.py) executes, it does not set g.v, whereas
this code previously assumed that g.v : (None + User) and did not
check for its presence.