* Sorted privileges into categories, similar to the v4.3 style
Added privilege check utilities:
* Forum: is_news(), is_default_accessible() and is_default_postable()
* Member: can_access_forum(), can_post_in_forum(), can_edit_post(),
and can_delete_post()
Unfortunately current_user is not a Guest when logged out, so one
cannot usually write current_user.can_*() without checking for
authentication first, so the checks are still somewhat verbose.
Reviewed forum permissions; the following permission issues have been
fixed (I have tested most but not all of them prior to fixing):
* app/routes/forum/index.py: Users that were not meant to access a
forum could still obtain a listing of the topics
* app/routes/forum/topic.py: Users that were not meant to see topics
could still read them by browsing the URL
* app/routes/forum/topic.py: Authenticated users could post in any
topic, including ones that they should not have access to
* app/routes/posts/edit.py: Users with edit.posts (eg. mods) could edit
and delete messages in forums they can't access (eg. creativecalc)
* app/templates/account/user.html: Users with admin panel access would
see account editing links they can't use (affects developers)
* app/templates/base/navbar/forum.html: The "Forum" tab would list all
forums including ones the user doesn't have access to
* app/templates/forum/index.html: Users would see every single forum,
including ones they can't access
* app/template/widgets/thread.html: Anyone would see Edit/Delete links
on every message, even though most were unusable
Miscellaneous changes:
* app/routes/forum/topic.py: Ordered comments by date as intended,
which I assume worked by chance until now
* Removed the old assets/privs.txt files which is now superseded by the
list implemented in app/data/groups.yaml
This commit changes group and forum information, run master.py with:
@> forums update
@> groups update
This commit introduces a client-side table filter that supports regexes
and propositional logic to filter table rows.
A table can be filtered if it has the [filter-target] class and its
first row has <th> tags with a [data-filter] attribute specifying column
names.
The filter itself is a div with the [form] and [filter] classes, and a
[data-target] attribute pointing to the table to filter. The filter
contains a text <input> which is passed to filter_update() when the
filter expression is validated.
The client-side filter code runs the expression through a basic lexer
and parser, then matches the result for every row in the target table.
The [textContent] of each cell is used for string and regex matching.