Danbooru

Danbooru 1.13.0 change log

Posted under General

None of these changes are live yet.

- Rails 2.0 compatibility.
- The biggest change is that several .js actions are now .json. Anything that returned a data structure now uses the .json extension.
- Several new config settings that let you customize user levels, tag types, and whether or not a user can see a post.
- Mods can unblock users.
- Artists can now have an arbitrary number of URLs associated with them.
- Normalized artist URLs are now stored in a separate field.
- You can now give a reason when submitting new aliases or implications.

Updated by petopeto

albert said:
- Several new config settings that let you customize user levels, tag types, and whether or not a user can see a post.

Hmm... Sorry if this is a stupid question but: is this for individual (selected?) users, or user groups?
Also... Why would (or should) anyone disable a post from someone else?

albert you are doing a really great job, and I want to thank you.

So thank you for what you do, please continue.

darkship said:
Hmm... Sorry if this is a stupid question but: is this for individual (selected?) users, or user groups?
Also... Why would (or should) anyone disable a post from someone else?

This is for people who also run the danbooru engine. Like konachan, moe.imouto etc. It allows the site admin to customize it for their purposes. It's not for users of the site to change.

piespy said:
This is for people who also run the danbooru engine. Like konachan, moe.imouto etc. It allows the site admin to customize it for their purposes. It's not for users of the site to change.

Oh. I see.
Thanks for the explanation. ^_^

Thanks for all the work.

Just a little note on the changelog list, "Rails 2.0 Compatibility" makes it look like it's still compatible with the old one.

Thanks for all the work, the new mass edit shortcut on the artist pages is definitely going to be useful! As is infinite URLs. Great stuff :)

Just one bug--I don't seem to be able to change tags to different tag types (ie. artist), like in post #209521. I tried both adding "artist:" to the tag and editing it in the tags page, neither seems to do anything.

EDIT: Hmm... Seems to work again?

Updated

favorite/show was removed because it was redundant. Search for fav:albert in the post listing instead.

This makes it to where clicking on any of the "Favorited by:" links leads to a non-existent page. Is there any way that these can be directed to the user's user page, now that favorite/show was removed? I've been replacing "favorite" with "user" in the link after hitting the 404 page to get to the user's favorites, but it would be more convenient if it went straight to the user page.

albert said:
favorite/show was removed because it was redundant. Search for fav:albert in the post listing instead.

The order is by ID, though, where as it would be more convenient if it were by date favorited, like before.

I agree with opem. It was much easier to find recently favourited pictures then, as well as easier to remove images from your favourites.

I would vote for a return to the previous way of doing things. It didn't feel very redundant to me.

-Eruru

Eruru said:
I agree with opem. It was much easier to find recently favourited pictures then, as well as easier to remove images from your favourites.

I would vote for a return to the previous way of doing things. It didn't feel very redundant to me.

-Eruru

Agreed.

Especially with removing favourites, which before was very quick and easy.

I've added an order:fav metatag to order by when the post was favorited.

I've also fixed the favorited by listing in post/show.

Could make "add favorite" in the quick edit box "toggle favorite" instead. But, without some indication of whether a post is favorited already, it would be easy to accidentally un-favorite something when you meant to add it and forgot that it was already done. It would need an indication of favorited or not for each post, like the border colors, but without making fav:self ugly.

Also, it wouldn't update the list after editing like the old delete box did. That's a more general problem; quick editing doesn't update the display. That'd be nice to fix. If the post no longer matches the search it's in, remove or hide it; update parent/child/flag borders dynamically (when a parent: tag is used or quick-flag); make the edit-tags box show correct tags if you quick edit it more than once without reloading.

  • 1