Desired behavior for new posts when FilterNewPosts setting is enabled
is that people with admin_level >= 2 and post authors should see their
post on the frontpage, while all other unprivileged users shouldn't.
The logic for this is already in `files.helpers.listing` but it was
overridden by a second filter condition which required `state_mod =
VISIBLE`.
`(state_mod = VISIBLE | author_id = v.id) & (state_mod = VISIBLE)`
simplifies in an unfortunate way. The latter condition was also not
conditional on admin_level. Simply removing it fixes the listing
for both post authors and privileged users.
it's kinda hard to give a good description but this fixes a bug where
the raw HTML of a post's content (not mediated by `realbody`) is being
sent to the `submission_banned.html` template. it also fixes the
formatting.
Handle a couple places with `t3_` that persisted from code movement.
on master after time of branch.
Then, fix commenting, which used inaccurate fullname parsing logic.
because of #606, we now have a relatively decent way of representing
how post/comment state is in the database. we'll use this in our code
which is used to determine what is shown in the UI
The notifications schema is already set up for reddit-style
chronological notifications. We simply have to remove the logic that
builds the context and patch up a few places in the frontend that
were expecting full reply trees.
`Comment.header_msg` previously expected the user's own comment to
be top-level in comment replies. Logic is revised to expect the actual
reply.
`files.routes.front.notifications_main` now has reduced query volume
because we aren't expiring the session when marking notifications read.
This also allows us to remove the unused `comms` variable, which is a
makeshift "pattern" of storing duplicate database replies across a
commit so the templates don't requery (thus losing data attached to
the runtime object, like `c.unread` / `c.notif_utc`).
We move the `is_notification_page` flag to the route callers rather
than templates checking `request.path`.
Minor UI style: "Clear all notifications" -> "Mark All Read", since
this was a persistent point of user confusion upstream, with people
expecting their inbox to empty out. Also less margin between notifs
to be consistent with tighter comment display elsewhere and removed
need to separate groups of comments vs single comments.
Change the notifications subpages to be distinct route handlers with
actual paths rather than query parameters. They already were a massive
conditional chain with almost no common logic.
Hard wrap some of the more egregious query lines. Use less duplicated
code for shadowban exclusion.
Only major functionality change which is somewhat related to #476 is
to sort subtrees by Comment.id DESC. Otherwise, upstream is
substantially the same as TheMotte. Given that upstream didn't
experience #476, I think the issue may have been resolved by prior
changes to filtering / comment visibility & moderation.
In the distant past, the codebase would check pushshift for keyword
mentions and generate notifications to admins about them. I can't
find where we removed it, but I don't think it was ever operative.
Since these notifications don't get generated, we don't need a
notifications page for them.
Fixes#612. Ports in an existing working fix from upstream with
the change to bs_trigger. Also a stylistic improvement on the
preceding line I noticed while porting it.
bs_trigger is what attaches the event listeners for the Boostrap
popovers. It wasn't being called on the new elements, so they get no
user card. It is now, so it does. Calling it on the comment form
element doesn't work here because, unlike in an earlier stage of the
codebase (which I think the fork occured during the transition of)
put replies into a dedicated element rather than replacing the reply
form.
* Use sessionmaker instead of context block
Essentially there were two bugs:
1) The logging lines before explicit `Session.begin` caused the root
"A transaction is already begun on this Session.", which is
resolved by moving the logging within the explicit session block,
as intended.
2) We were reusing a Session across cron runs. The architecture was
intended to not do so, but we didn't have an actual sessionmaker
available to cron. We probably ought to get rid of scoped_session
elsewhere, but baby steps to resolve the immediate issue.
In testing, this works correctly with the fix to `db.begin`, and
tests with deliberately reintroducing the logging bug, the changes
to session creation prevent the every-15sec stack trace spam.
---------
Almost-entirely-authored-by: TLSM <duolsm@outlook.com>
