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>
This one was kind of a doozy. This also adds a custom 403 error page and
fixes some permission denied behavior that I was having issues with for
a while.
This is also set up in a way that hopefully will allow me to easily
implement user post deletion.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
If a user *really* doesn't like a post, they may try to report it
multiple times. Users may now only report a single post once per IP
address.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
This allows users to hide posts that they may find unsavory. On threads
themselves in the board view, this adds a minus/plus button that will
toggle back and forth if hidden. This also adds a post menu item that
will toggle a post being hidden.
This also changes the post snippet layout a little bit. This caused
minor issues with the other menu items, but it should be fixed in this
set of changes too.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
If a user hovers over an image with their mouse, it will load the image
and display it in the corner.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
The post number, username, subject, etc all come before the an image (if
there is one) now, rather than sorta wedged afterwards. This seems to be
working.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
When a user makes a new post with a name set, it will get saved via a
cookie to the user's client and it will automatically get set the next
time a user makes a post.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
* BoardMixin adds a cached property that gets the current viewed board -
this assumes that there is a self.kwargs["url"] value available.
* can_modify now checks for some more permissions.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
* Boards can be locked from allowing posts - this is can be useful for
things like archived boards or locking down in the event of an
emergency
* Some validation checks for new posts are from the reply/thread form to
the Post model's clean() method
* Add some new tests, I've really been falling behind on those
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
I was surprised to see that the site is already pretty mobile-friendly.
The main issue was the quick reply, new thread, and report
windows - they were all hard-coded to be 500px, 500px, and 360px wide
respectively. Now, those hard-coded widths are the default but if the
viewport is thinner than that, the new window will size itself down with
some padding.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Some windows have a variable height based on the user's permissions
(e.g. having a capcode option). This sets the window height to the
minimum requiremed height based on the document loaded in.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
This prevents all stickied threads from having their own bump order. We
want stickies to all stay in the same order.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
can_modify needs to be present in order to load the modify.js script.
This wasn't present on the PostView and was on a couple of unnecessary
views.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
