Danbooru 2 Issues Topic

Yuichi_Nietzche said:

Not sure when this started, but when I went to save a tag to my save searches I couldn't find the "save search" button any more.
Disabling my extensions and user scripts didn't help, and tried with Chrome as well but no cigar.

Check if you have any Custom CSS set in your Danbooru settings. That's what caused the issue for me. See earlier posts in this thread:

• The Custom CSS issue: forum #128814, forum #128816
• Updated CSS that works: forum #128821
• Post about updating Danbooru Miscellaneous Tweaks script: forum #128858

Trying to visit my profile makes the page load forever and gives me a Failbooru after a while, anyone else?

EDIT: Or rather any profile does this.

Same here...

There were no recent site updates, so maybe it's just a transient issue...?

It seems like it's the same with post changes too, both on posts and recent changes.

EDIT: It seems to be working again, yay!

@albert the archives sqs processor may be hung up. /post_versions stopped updating about 12 hours ago.

I can't figure out how to edit my Saved Searches :|

Kikimaru said:

I can't figure out how to edit my Saved Searches :|

https://danbooru.donmai.us/saved_searches

Or you can get there by clicking "Saved searches" on the post screen, and then "Manage saved searches"

Once you're there, each search should have it's own "edit" button.

This is a weird one.

I have noticed that sometimes after Moonspeaker has translated a post, the tag history bugs out.
If you check posts like post #2691343, post #2689658, post #2686074 you'll see that the original tagger has completely vanished. At least on my end.

Nothing major, just an observation.

Hmm, that sounds like version merging is going haywire, but I don't see the flaw in https://github.com/r888888888/archives/blob/master/models/post_version.rb#L30.

@Moonspeaker, do you use anything special to mark post as translated, or just danbooru's built-in "mark as translated" button, or do you add the tags manually?

Type-kun said:

Hmm, that sounds like version merging is going haywire, but I don't see the flaw in https://github.com/r888888888/archives/blob/master/models/post_version.rb#L30.

@Moonspeaker, do you use anything special to mark post as translated, or just danbooru's built-in "mark as translated" button, or do you add the tags manually?

For the "translated" tag, I use the "mark as translated" button.

I think I noticed something like this on post #2687933 a few days ago; I found some erroneous character tags and was curious who had added them, but the Tag history didn't include the original tagger. Now it's fixed. Doing a quick check...okay, that's not right. The Tag histories of #2691343 and post #2689658 show me as the original tagger, which isn't true; I just translated them. I have no idea why this is happening.

Created issue #2972. The problem appears to be that edits containing the pool:<name> metatag aren't recorded. This is a very subtle bug caused by a change I made to try to fix issue #2950. I think this may have caused any edits using the pool metatag since 2017-04-01 to have been not recorded in the tag history.

Wait, I think I figured it out. It's one of two things:

• post versions were delivered to archive out of order. Moonspeaker's (initial tags -translation_request +translated) was first and was recorded first, then came Randeel's initial version (initial tags only, -translated +translation_request), then Randeel's edit adding commentary_request (Moonspeaker's tags +commentary_request) which was merged with previous one, leaving it as only adding "commentary_request";
• initial version wasn't delivered at all, so Moonspeaker's was recorded as the first one.

@Albert, is there any logging enabled, can you please find out what actually happened? Messing up version archives might break other features, like reversions or change searches.

E: damn, sniped. Well, it's the second case then, and that was unexpected.

Yeah, judging by the /uploads.json records, all these posts were initially tagged with the pool metatag. This caused the initial version to not be sent because of a very tricky interaction between adding pools and creating versions, which caused Moonspeaker's edit to be recorded as the first version.

The easiest way to trace what's happening is to stick binding.pry inside create_version to create a breakpoint, then you can inspect previous_changes and see how it's wrong.

Site update (2017.04.04 - 2017.04.14)

Features

• Bulk update request approvals/rejections now update the thread's title.
• The /bulk_update_requests listing now color codes BURs by status (moderators only).
• The /post_flags and /post_appeals listings were redesigned. Now these listings can be searched by tags and they have columns listing uploaders and approvers.
• API: new IQDB endpoints were added:
• GET /posts/1234/similar.json
• GET /iqdb_queries.json?post_id=1234
• GET /iqdb_queries.json?url=<url>

Changes

• The flag and appeal dialog boxes now support dtext preview.
• Wiki pages now give a warning if you try to rename a wiki entry without moving the tag first.
• Approvers: the Approve and Undelete links in the sidebar now ask for confirmation first.

Fixes

• Fixed an exception on /artists when using the search[empty_only] param (example: /artists?search[empty_only]=true&search[name]=hammer*).
• Pool autocomplete incorrectly excluded pools marked as inactive.
• Wiki and artist autocomplete incorrectly included deleted wikis/artists.
• Wiki and artist autocomplete returned the most recently updated wiki/artist entries first, which gave bad results and was unlike how tags are completed elsewhere. Now tags are completed the same way everywhere.
• Various optimizations for /artists.json, /wiki_pages.json, /pools.json.

Full changelog: https://github.com/r888888888/danbooru/compare/production-2017.04.04-203407-utc...production-2017.04.14-201953-utc

@evazion

Are the POST endpoints for "/iqdb_queries.json" going to be deprecated eventually?

I think it should be deprecated and removed at some point, yes. POST doesn't make much sense for IQDB lookups since it doesn't modify anything. But I don't know if anyone depends on the "POST /iqdb_queries" endpoint so I left it alone. We should probably figure out some kind of versioning strategy or deprecation process to allow for making changes like this to the API.

Ah good. I was just wondering how much time I had to change my code. When it does get deprecated, it would be nice if one of the Admins put up a notice on when the changeover will occur.

On a side note, I noticed that the behavior for the post_flags and post_appeals now follows the posts behavior, i.e. deleted posts are not automatically seen unless you add the status:deleted tag. That's not bad... it just threw me off. I'll have to see about updating the wikis to include that little tidbit.

Edit:

Nevermind, there really isn't a wiki... :/

evazion said:

• The /post_flags and /post_appeals listings were redesigned. Now these listings can be searched by tags and they have columns listing uploaders and approvers.

Did /post_flags always include posts unapproved after three days? That seems to cause quite some clutter/noise. Maybe “Include unapproved posts” could be a search option that defaults to “No”?

Noticed a pretty big issue with /post_appeals. The resolved drop down doesn't have a blank value, so this basically creates a situation where two values have to be changed in order to see deleted posts with appeals when using the tag input function.

1. status:deleted needs to be added to the tag input.
2. Resolved needs to be set to false.

The above is just a UI issue though, since if search[is_resolved] is manually removed from the URL, then it works as expected. (Similar to the /post_flags as I noted above).

On a side note, I noticed that the behavior for the post_flags and post_appeals now follows the posts behavior, i.e. deleted posts are not automatically seen unless you add the status:deleted tag. That's not bad... it just threw me off. I'll have to see about updating the wikis to include that little tidbit.

Hmm, I think it's following the "Deleted post filter" setting if you have that setting turned on. Not sure if that's desirable behavior or not.

Did /post_flags always include posts unapproved after three days? That seems to cause quite some clutter/noise. Maybe “Include unapproved posts” could be a search option that defaults to “No”?

It did. You can set the category to Normal to show only "normal" flags, that is, flags added by users, not automatic "Unapproved in three days" flags. The category options could be better named and explained and perhaps normal could be the default.