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>
* 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>
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>
Fields are only displayed via the PostModifyForm if the user has
specific permissions to do things, like set stickies.
Also, add PostModifySuccessView that will close the modify window when
the process is complete.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
New threads get a floating window just like new replies have. This only
pops up on the board detail view.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Sometimes, it is necessary for an admin or other moderator to reveal
themselves. Capcodes allow them to do so by appending a special colored
portion at the end of their name on a post.
This adds object-level permissions, so if you have a moderator who
shouldn't be able to use the "admin" capcode, you can give them
permission only to the "moderator" capcode.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
If a user had a permaban, there would be a comparison error between the
current time and the expiration time (none).
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Winbox has this annoying bug where you can't move the window below the
calculated area of the document, so you can't drag it over blank space.
JSFrame fixes this and does basically what we want as well. This has
been implemented for post replies and I am going to implement it for
reports and ban creation too.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
The artist formerly known as CreatePostView is a little more generic now
and outsources its ban check to a new util method, is_banned.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
On the success page for bans and reports, the window can now be
configured to close after N seconds if desired.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
This is done in the admin view and opens a new iframed window. The ban
form is pretty barebones and doesn't have full functionality yet, but
that is coming.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
If a user had a ban previously, range-ban or single IP, which has since
expired, they will not be redirected to the "you are banned" page and
the active bans are deleted.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Users can be banned by IP address now, either by singular IP or in an IP
range. If they are banned and attempt to post, they will be met with a
"you are banned until X date" screen.
There are a few loose threads with this, and IP bans may be obsolete if
I decide to go the accounts-required-for-posting route. But I think this
is a good start for 4chan style posting.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
* There are now Reports and ReportRecords.
* Reports coordinate to what moderators see, and ReportRecords
coordinate with the reports that are created by individual users.
* Reports keep track of the report reason and the creating user.
* ReportRecords keep track of the total weight and whether this report
requires urgent attention or not.
* ReportRecord keeps track of its own weight and urgency because then we
can sort by weight and urgency in the admin view.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
The report system is pretty low-tech. However the scaffolding is there
for a lot of new stuff. What we currently have:
* Users can create reports
* Staff can view reports
* Admins can create report templates
There's a post drop-down menu available on all posts now, too. This is
where "report post" menu item lives and other things like that can be
added too.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Previously, you could browse /board/ and /board/page/1/ in the browser
and they would be the same thing. Now, /board/ redirects to
/board/page/1/ to keep things unambiguous.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
If a user tries to post more than once in a certain amount of time, they
will be blocked from doing so until their cooldown is over. This
required a little bit of hacking to get the board and IP address set
*before* the validation checks were made, but it all appears to work.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Each board is allowed a number of threads per page, and a maximum number
of pages (default 10 for both). If a thread falls off the last page, it
is deleted.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
Images can be uploaded, thumbnails are created, they're displayed within
the threads themselves. Just like four chans!
There is not an upload size limit set yet. Gotta get on that next.
Signed-off-by: Alek Ratzloff <alekratz@gmail.com>
