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.
Bug: Post.fast_count failed when Danbooru.config.estimate_post_counts
was enabled but the database didn't have any posts. This normally
happened only during testing.
Hide IP ban creation and deletion actions from non-mods in the
/mod_actions listing.
The previous approach of just filtering out the IP from the description
was hacky and didn't work with the `only` param (/mod_actions.json?only=id
still included the description field).
* Switch CloudflareService from HttpartyCache to Danbooru::Http.
* Purge cached urls from Cloudflare when a post is replaced and the md5
doesn't change. This happens when a corrupted image is replaced or
thumbnails are regenerated. Before we purged urls when a post was
expunged, which was unneeded because those urls can expire naturally.
It was also wrong because the subdomains were hardcoded, the urls used
http:// instead of https://, and we didn't account for tagged urls.
* Open recommendations to all users (not just gold).
* Show recommendations on all posts (not just posts after 2017).
* Allow users to browse recommendations for other users.
* Increase number of recommended posts returned.
* Change endpoints to /recommended_posts?user_id=1234 and
/recommended_posts?post_id=1234 and add json/xml support.
Don't track IP addresses for post appeals, post flags, tag aliases, tag
implications, or user feedbacks. These things are already tightly
limited. We don't need IPs from them to detect sockpuppets.
Add `Danbooru.Autocomplete.MAX_RESULTS` param that controls the number
of results returned by autocomplete.
This does not work with tag autocomplete for Builders. Builder
autocomplete still needs to be refactored and unified with Member
autocomplete.
Also fix a bug in the /saved_searches/labels endpoint where the limit
param wasn't respected.
Add a new IP address search page at /ip_addresses. Replaces the old
search page at /moderator/ip_addrs.
On user profile pages, show the user's last known IP to mods. Also add
search links for finding other IPs or accounts associated with the user.
IP address search uses a big UNION ALL statement to merge IP addresses
across various tables into a single view. This makes searching easier,
but is known to timeout in certain cases.
Fixes#4207 (the new IP search page supports searching by subnet).
Sometimes uploads fail with this error:
ActiveRecord::QueryCanceled - PG::QueryCanceled: ERROR: canceling
statement due to statement timeout CONTEXT: while updating tuple
(2808,110) in relation "tags"
This is caused by two uploads trying to update tag counts for the same
tags at the same time. The UPDATE statement doesn't guarantee the tags
will be updated in any particular order, which can cause deadlocks when
two UPDATEs try to update the same tags in a conflicting order. For
example, if one process tries to increment '1girl' and 'solo' (in that
order), while at the same time another process tries to increment 'solo'
and '1girl' (in that order), the result will be a deadlock.
The solution is to explicitly lock the tags in a consistent order before
the update statement.
