- Posts and topics have an added moderation_reports function
-- This is so all moderation reports can be loaded in a single query
- Those moderation reports are passed into the render functions separately
-- This is so the individual comments/posts don't have to be queried
- Limited to Builders+
-- Moderator+ can also use as they may be too busy ATM
- Only on users, comments, and forum posts
- Multiple reports can be generated per instance
- Primarily posts to a moderator-only topic for viewability
- Secondarily has a table for searchability
-- Viewable only by moderators
* Rename 'privacy mode' to 'private favorites'.
* Make the private favorites setting only hide favorites, not favgroups
and not the user's uploads on their profile page.
* Make the favgroup is_public flag default to true instead of false and
fix existing favgroups to be public if the user didn't have privacy mode
enabled before.
* List _all_ public favgroups on the /favorite_groups index, not just
favgroups belonging to the current user.
* Add a /users/<id>/favorite_groups endpoint.
Unify the `name_to_id`, `named`, and `find_by_name` methods into a
single `find_by_name_or_id` method that has consistent behavior in how
names are normalized.
Remove restrictions against flagging too many posts by the same
uploader. This had problems with preventing legitimate flags in some
cases, particularly with old legacy content. This will be policed
manually instead.
* Convert notices from helpers to partials.
* Eliminate PostSets::PostRelationship class in favor of post_sets/posts template.
* Eliminate COUNT(*) queries when calculating the number of child posts.
* Eliminate redundant parent load and parent exists queries.
Remove uses of the is_active flag. Keep column in database (for now).
The only purpose of this flag was to filter out pools from the pool list
in the Add to Pool dialog. This hasn't had much use since autocomplete
was added. Most pools didn't set the flag correctly anyway.
Fix regression caused by 3d3f61559. This is what happened:
* The posts controller calls post.visible? before post.update.
* post.visible? calls post.tag_array.
* The call to tag_array causes the current value of tag_string to be
cached in @tag_array.
* post.update calls post.merge_old_changes.
* post.merge_old_changes accesses tag_array, which contains the old
cached version of tag_string rather than the new version from the
update.
* post.merge_old_changes detects no changes, so the update does nothing.
* This only happens for Members because for Gold+ users the call to
post.visible? short circuits before accessing tag_array.
Moral of the story: cache invalidation is hard. Don't cache unless you have to.
Bug: on the forum index, clicking on 'page 290' of the Danbooru 2 Issues
thread leads to an empty page. The last page is actually page 288.
Cause: 89df0a6ac changed it so that deleted posts are filtered out of
threads, but this made the calculation of the last page incorrect. The
last page is calculated from the topic's response_count, but the
response count includes deleted posts.
Fix crash on /ip_addresses page when using the group by option. Caused
by attempting to include model_id in the data attributes when it isn't
present when using this option. Fix is to only include attributes that
are actually present.
- In some cases deleted items weren't visible from the index view
- There also shouldn't be any reason why they can't be shown when searched for specifically
-- This also matches the behavior on comments
* Warn when renaming a wiki that still has links from other wikis.
* When renaming a wiki that still has posts, just show a warning instead
of returning an error and making the user confirm the rename.
