If a user hovers over a reply link to a post, it will highlight that
reply (if it exists). Also, all replies to a post (that are visible) are
added as another element to that post.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
If a user hovers over a reply link, that reply is highlighted.
Obviously, this is only useful if the reply is on-screen.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
The ReplyBuilder does stuff like parsing >quotes, >>replies, and
[spoiler]spoiler tags[/spoiler]
We mostly want to track consistent behavior with this
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
While it's a neat idea to put it on every page, it was also appearing on
*every page* - including stuff like "delete post" page and reply windows
and stuff.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
* nginx needs to add X-Forwarded-For and REMOTE_ADDR headers to get the
IP address properly
* uwsgi now logs 400 errors and adds the REMOTE_ADDR to the log file
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
* db directory in root usually holds production data and causes git to
complain about not being able to read it
* static directory in root holds the collected static files which are
regenerated/collected at build time
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
When a new deployment is created, or when new settings are added, we
want to avoid overwriting settings that may already be present. So we
use the settings.example.py file for default settings and settings.py
for deployment settings instead.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
I was putting this off during initial development so that experiments
and toying around with models would not be saved in the history,
especially if rebuilding the entire database was required. Now that the
models are in a more stable place, we can start tracking migrations.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Wiping is done via a single user post. It will search for all posts by
that IP address *or* user token and delete them.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
If a user has spammed a lot of posts and made a mess of the board, this
will allow us to delete all posts by the offending user from the same
IP.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Further in on restricted JS to simplify things. Rather than breaking out
all Javascript stuff into their own granular files, this just includes
all admin actions together in the same file.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
The URL routing for /banned/ was going to the board controller because it
would match /banned/ as a board URL rather than its verbatim value. This
is fixed by moving the board route match to the bottom of the URL
routing list.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
For both ban and modify actions, we trust staff users to not abuse
otherwise-secret scripts and links. We don't supply "can_modify" context
variable anymore and just use user.is_staff instead. The same goes for
ban links and scripts.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
ActionSuccessView is a a generic view that indicates that something was
successful, e.g. deleting a post or banning a user. This hopefully
reduces the amount of boilerplate code used for creating success pages
since most of them can derive from this generic view.
The report and delete success views are updated to use this directly.
The ban and modify success views are updated to derive from this class,
with special permissions required.
The post success view is updated to derive from this class, using a
different template.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Users can delete their posts as long as they don't clear their cookies,
and as long as server-side user sessions are persistent.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
