parasprite said:
#1 is part of an ongoing fix up that still needs a lot of work.

#2 is a good idea, I'll push that now.

Edit: Something like this?

Do existing strings in source fields stick around?

Lance_Armstrong said:
Do existing strings in source fields stick around?

Essentially old invalid URLs would stick around until somebody fixed them, but no new ones would be allowed (at least that's the idea). At this point I'm mostly focusing on cleanup and making the purpose of the source field more obvious.

Oh, and getting the source field to link non-www/http links (e.g., e621.net), which shouldn't be too difficult to do I just haven't gotten to it yet.

parasprite said:
Essentially old invalid URLs would stick around until somebody fixed them, but no new ones would be allowed (at least that's the idea). At this point I'm mostly focusing on cleanup and making the purpose of the source field more obvious.

Oh, and getting the source field to link non-www/http links (e.g., e621.net), which shouldn't be too difficult to do I just haven't gotten to it yet.

untested, backslash replaced with #

(https?|ftp)?(:#/#/)?(www[0-9]?#.)?(.*)#.(.*)#/(.*)

Requested feature:

A "Random post from search" button.

Why?

Sometimes I want something specific to a certain character/species/tag, but I don't have a preference within that.

waffledoctor87 said:
Requested feature:

A "Random post from search" button.

Why?

Sometimes I want something specific to a certain character/species/tag, but I don't have a preference within that.

You can add order:random to the search bar for a similar effect.

For example:
Searching pokemon male solo order:random will return your search results in a different order every time you search for it (also the order changes if you refresh the page).

I hope that helps. :)

Requested feature: Option to filter tags by whether wiki exists

Why it would be useful: Make it easier to create wikis for tags

https://e621.net/tag?name=&type=3&order=count
https://e621.net/tag?name=&type=3&order=date

Requested: Wikis (notes) for artist tags should link to the artist page.

Lance_Armstrong said:

Requested: Wikis (notes) for artist tags should link to the artist page.

Personally I'd prefer to merge the artist interface into the wiki instead (have it pull up the proper page by tag type), but barring that it shouldn't be hard to automatically add a link to the artist page (and vice versa).

I love the first idea though.

Lance_Armstrong said:
untested, backslash replaced with #

(https?|ftp)?(:#/#/)?(www[0-9]?#.)?(.*)#.(.*)#/(.*)

That works for both e621.net/ and ./ but not e621.net

something like ...|.*#.(com|net|org|etc)(#/.*)? might work well enough though.

parasprite said:
That works for both e621.net/ and ./ but not e621.net

something like ...|.*#.(com|net|org|etc)(#/.*)? might work well enough though.

It requires a / because linking to a home page is useless.

Changed:

optional protocol
(:#/#/)? optional "://"
(www[0-9]?#.)? optional "www.", "www2."...
([^.]+) mandatory 1+ non-dot characters
#. mandatory dot
([^.]+) mandatory "net", "com", "z", "1" accounts for all new gtlds
#/ mandatory forward slash
(.+) mandatory 1+ characters

merged first two groups

and a fix for matching aaaaa://aaa.com/aaa

and fix for http://aaa.com//aaa

Lance_Armstrong said:
It requires a / because linking to a home page is useless.

parasprite.tumblr.com :P

parasprite said:
parasprite.tumblr.com :P

For tumblr I link to the individual post pages.

e.g. http://elpatrixf.tumblr.com/post/133019877287

Saves loading a lot of extra junk. Your choice.

Lance_Armstrong said:
For tumblr I link to the individual post pages.

e.g. http://elpatrixf.tumblr.com/post/133019877287

Saves loading a lot of extra junk. Your choice.

I just meant it's common for people to link stuff like that, especially artists.

parasprite said:
I just meant it's common for people to link stuff like that, especially artists.

Doesn't make it not useless.

Well okay, not entirely useless, but not as useful as a link to the post page. Given the post link it's trivial to find the tumblr, even if the post gets deleted, but given only the tumblr it can take a lot of effort to find the post.

Now, for something like furaffinity a link to the artist's page would make sense (ideally alongside a link to the post page), since /view/<ID> provides no way to find the artist if the post page is inaccessible (deleted, or you're not logged in and its set to require login), but furaffinity uses /user/<username> so it wouldn't fall afoul of that filter. Is there anywhere that uses subdomains for the artist page and also has opaque post URLs?

Snowy said:
Doesn't make it not useless.

Well okay, not entirely useless, but not as useful as a link to the post page. Given the post link it's trivial to find the tumblr, even if the post gets deleted, but given only the tumblr it can take a lot of effort to find the post.

It's not ideal, but for an artist it's how they are probably used to linking to their main gallery. Since it is a valid URL I don't see why we'd exclude it.

Edit: hassource:true -source:/ looks pretty handy for going through these. I'll have to bookmark that one for later use.

Snowy said:

Is there anywhere that uses subdomains for the artist page and also has opaque post URLs?

Nothing that I know of that is relevant to here (or otherwise). Usernames are common but I've never seen anything like a member ID there.

We need some way to search for posts that have been tagged by a specific user.

That'd make mistags far easier to fix. For instance, there was one banned user who tagged sheath on pretty much everything. Being able to search for something like 'taggedby:<username> sheath' would make those simple to fix.

Even after a couple of years, I'm still constantly running into those. The only way to fix them all would be by checking every post tagged as sheath, one by one. All 15000+ of them. I remember trying that, and then giving up after several months of work. It was too ineffective to do manually.

REQUEST:Implement an option to disable thumbnail outlines.

I'm tired of seeing the green/yellow outlines on the thumbnails.

Thank you.

Genjar said:
The only way to fix them all would be by checking every post tagged as sheath, one by one. All 15000+ of them.

This puzzles me. Isn't it automatable?
1. get a list of postids (ie the API-based equivalent of sheath)
2. use post_tag_history to get changes for that post id
3. If user listed in a record is the offending user, and sheath is listed as an added tag in that record, remove the sheath tag from that post.

Also seems like something that an admin could do quite efficiently, since they can directly wrangle the DB rather than having to jump through API hoops

Genjar said:
We need some way to search for posts that have been tagged by a specific user.

That'd make mistags far easier to fix. For instance, there was one banned user who tagged sheath on pretty much everything. Being able to search for something like 'taggedby:<username> sheath' would make those simple to fix.

There is the Tag History Index. Just click "Show Search Options" and enter what you're looking for. You might get repeat posts if a user tagged something multiple times, but it sounds like what you're looking for.

SaimonPSmith said:
There is the Tag History Index. Just click "Show Search Options" and enter what you're looking for. You might get repeat posts if a user tagged something multiple times, but it sounds like what you're looking for.

It's extremely ineffective when there are tens of thousands of mistags to fix. Not only is it hard to keep track of the pages in that search, it also tends to time out. And searching for a common tag such as sheath gets tons of false hits (instances where the post already has the tag, and the user in question tagged something else).

It's even slower than searching for the tag and checking each post one by one.

Genjar said:
It's extremely ineffective when there are tens of thousands of mistags to fix. Not only is it hard to keep track of the pages in that search, it also tends to time out. And searching for a common tag such as sheath gets tons of false hits (instances where the post already has the tag, and the user in question tagged something else).

It's even slower than searching for the tag and checking each post one by one.

Can confirm. It's slightly easier to just go through a user's tag history, but even that has its drawbacks.

Requesting the disable blacklist checkbox

Lance_Armstrong said:
Requesting the disable blacklist checkbox

yes please
Made this request a while ago, can't remember if anything happened

Also related is forum #167214 (separate & discrete blacklists for posts, users/comments, avatars, etc)
----------------------------------------------------

Any plans to implement this in future updates?

titanmelon said:
Requested feature: Corresponding links to artist entries and their respective wiki entries

e.g. crookedtrees' artist page: https://e621.net/artist/show/4394
And the wiki entry: https://e621.net/wiki/show?title=crookedtrees

Why it would be useful: The convenience of being able to access one page without manually searching for the other

Still applies to artist/wiki posts under the current site version.
For an example, try finding out if eric_schwartz is aliased to TDK from artist #606 the artist page

titanmelon said:

Also related is forum #167214 (separate & discrete blacklists for posts, users/comments, avatars, etc)

I think it would be simplest to just make a new metatag uploader:parasprite and leave user:parasprite to handle comment/user blocking.

titanmelon said:
Any plans to implement this in future updates?

Still applies to artist/wiki posts under the current site version.
For an example, try finding out if eric_schwartz is aliased to TDK from artist #606 the artist page

I'm hoping to gut the artist-specific pages and merge everything with the wiki and /tag/edit pages at some point, but the work is far from being done.

Requested feature:

Searching all images in a pool based on a search specifying the tags of only one of those images. E.g. group_sex m/m related_by_pool:"fav:zest comic" would search for all images that have the tags group_sex and m/m, and also belong in a pool from which I've favourited at least one picture (this picture also having the comic tag). These related pictures themselves don't necessarily have to be favourited or have the tag comic.

Why?

Favouriting the first page in a comic or other image series (in a pool) saves time and doesn't overshadow individual images favourited. But the tags of first pages are hardly representative of the rest of the comic, so searching for the comics you've favourited based on the tags found in the rest of the comic is usually not possible. Being able to search related images (e.g. based on pools, but can also be extended to child posts and sets) overcomes this problem.

Zest said:
Requested feature:

Searching all images in a pool based on a search specifying the tags of only one of those images. E.g. group_sex m/m related_by_pool:"fav:zest comic"

I think you want inpool:true.

inpool:true fav:Zest m/m group_sex

Close enough?

Requested feature:

A toggleable option for the random post button to respect a user's blacklist.

Riversyde said:
All bugs and request features can now be submitted directly to http://bugs.ouroboros.ws, as it is easier for us to track them there. You may still post feature suggestions here, and we'll add them to Mantis manually.

You may create your own account if you wish, but you can also just click Login Anonymously. Then click Report Issue at the top of the page to create a new bug report or feature request.

Ouroborus.ws is now defunct. Feature requests and bug reports will now be handled on-site.

Please report bugs in forum #28544, not in this thread.

Here's an easy template for making a feature request:

Requested feature:

Why it would be useful:

[b]Requested feature:[/b] 

[b]Why it would be useful:[/b] 

https://e621.net/pool/show/5665

How about we translate this, it's been up for a year now and still no translation

Lance_Armstrong said:
I think you want inpool:true.

inpool:true fav:Zest m/m group_sex

Close enough?

not at all...

ChangelingLumin said:
https://e621.net/pool/show/5665

How about we translate this, it's been up for a year now and still no translation

How about you post this in a thread where it is actually relevant? Translation has nothing to do with admins or feature requests, only to do with somebody who knows the language looking at the images and adding appropriate notes.

Right now the status search in flag history is ordered:

Deleted
Flagged
Active

Wouldn't it make more sense if it was flagged that went first?

I've noticed that there are five categories that all of the tags on e621 are placed under: Artist, Character, Copyright, General, and Species.

Is it possible to make a few more?

For example, all of the tags regarding color (monochrome, eye colors, hair/fur colors, etc) could be labeled under "Color". All of the tags regarding genders (because we all know there aren't just two) could be labeled under "Gender". And all of the tags regarding actions or acts (insertions, penetrations, sexual positions, etc) could be put under "Actions" or acts or something.

They've added some categories during my time here, so it's probably possible to add even more.

And it might be handy for easily spotting missing tags (or mistags), but on the other hand, it might end up looking too cluttered. Personally, I'd probably find some kind of sex-tag category most useful. Would make it easy to clean those off the safe posts, if they were all grouped together.

Requested feature:
Different colors for artist tags with and without a wiki

Why it would be useful:
It would be nice if you could, just by looking at the artist tag in the tag list, see if a wiki for the artist has already been created.

Example of a post with a wiki-less artist tag:
post #789539

Requested feature:
An option to blacklist a user in forums, comments, dmails, and blips exclusively (i.e. without blacklisting posts uploaded by that user)

Why it would be useful:
A user being irritating doesn't mean that their uploads are going to be bad.

GameManiac said:
I've noticed that there are five categories that all of the tags on e621 are placed under: Artist, Character, Copyright, General, and Species.

Is it possible to make a few more?

I've been thinking about that too. The new, ordered, and colored categories help a great deal in picking out important tags from tag lists, but I find that tag lists are still too long to quickly pick out specific tags that interest me.

I was thinking that a Basic section would be useful for taggers to spot missing or incorrect core tags. What's more, merely establishing a Basic tag category would prod the lesser tag-inclined users and uploaders to at least fill out that category. I'm not one to decide what should be considered Basic tags, but number of characters pictured (including none) and genders would be a good start.

Sex-related and sex-adjacent tags (like butt or bulge, pending discussion if needed) would logically belong to another group.

One day, e621 could support tagging via filling out a form for categorized tags and alert users to untagged common picture properties, and major taggers could more efficiently check for missing tags and tagging errors in bulk. I see increased tag organization, such as with categories, as a potential if not necessary step in order to reach that lofty goal. One day.

Munkelzahn said:
Requested feature:
Different colors for artist tags with and without a wiki

Why it would be useful:
It would be nice if you could, just by looking at the artist tag in the tag list, see if a wiki for the artist has already been created.

Example of a post with a wiki-less artist tag:
post #789539

Tags without a wiki could have their ? be red or grey, kind of like wikipedia. Maybe an off-color of whatever a user's theme is, so perhaps darker or lighter than the normal ? color.

I've proposed informal (ie. not distinguished by color) tag grouping in the past. There is some attempt at this on the wiki, for example poses, but IMO some kind of support from the e621 system would help : automatically list groups that a tag is in at the end of the wiki page for that tag; and query what tags are in a group.
Then, we would be able to work out informal groups .. informally.. and when it becomes clear that a group warrants an official different 'type' (color), the information would be usable by the admins to easily 'convert' that unofficial group into an official tag type.

(personally I think 'general' is far too huge in membership. 'clothing/accessories' is one obvious subset of it, with 'anatomy' being another; 'scene' might be another (tags relating to viewing angle, background, grey/mono/transp/animated, 'multiple scenes in one image' tags..))

savageorange said:
(personally I think 'general' is far too huge in membership. 'clothing/accessories' is one obvious subset of it, with 'anatomy' being another; 'scene' might be another (tags relating to viewing angle, background, grey/mono/transp/animated, 'multiple scenes in one image' tags..))

Those are great. Scene in particular should apply to just about every post, and it'd be easy to figure out which tags go under there. That'd significantly cut down the number of general tags.

Requested feature:
Discourage users from direct-linking to images in Source.
(refuse links entered into Source which end in ".jpg", ".png", etc?)

Why it would be useful:
A direct link to the same image on another site isn't very helpful, especially if they didn't add an artist tag.

avoiddancee said:
Requested feature:
Discourage users from direct-linking to images in Source.
(refuse links entered into Source which end in ".jpg", ".png", etc?)

Why it would be useful:
A direct link to the same image on another site isn't very helpful, especially if they didn't add an artist tag.

The site allows you to upload images with a direct link as an alternative to choosing a file, so this isn't really an option.

Though it would be nice to push those links to the bottom of the source list by default.

parasprite said:
Though it would be nice to push those links to the bottom of the source list by default.

It'd also be nice if there were a way to search for images that only had direct links as the source. There seem to be a lot of them popping up lately and normal no-source searches leave these laying around effectively sourceless.

Since (relatively) few total images currently have direct links, it's possible to try hunting some of this sort of thing down doing searches along the lines of source:jpeg for each extension type. Problem is that this also shows images that have additional sources.

Maybe we could get a 'sourcecount' search term so we could do search for one source with 'X' extension?

Wodahseht said:
It'd also be nice if there were a way to search for images that only had direct links as the source. There seem to be a lot of them popping up lately and normal no-source searches leave these laying around effectively sourceless.

Since (relatively) few total images currently have direct links, it's possible to try hunting some of this sort of thing down doing searches along the lines of source:jpeg for each extension type. Problem is that this also shows images that have additional sources.

Maybe we could get a 'sourcecount' search term so we could do search for one source with 'X' extension?

Not a bad idea, but it seems to me the problem you are actually expressing isn't searching for sources with X extension, but searching for sources that have -a- extension, whose extension is not html/htm/php/cgi. If that's the case, perhaps a special value for source could be used to represent that? Then that could be combined with the sourcecount idea.

(this should catch most 'unhelpful' links, but not all of them. Consider source:imgur.com/a )

Direct image links aren't useful as sources. Maybe there should be a separate field on the upload page for uploading via URL.

leomole said:
Direct image links aren't useful as sources. Maybe there should be a separate field on the upload page for uploading via URL.

Only I've seen to be useful are deviantArt's file names, since most (if not all) have the fav.me key included

leomole said:
Direct image links aren't useful as sources. Maybe there should be a separate field on the upload page for uploading via URL.

I always end up using two lines at the same time to have the first one be the direct image, then just delete that first line after uploading, but I agree that it would save time if we were able to use the direct URL as the Upload From field.

Request,
width: 100% height: auto CSS for non-logged in users.

Why it is useful,
I have to login to have images scale to my window size. For some reason - images to do not get scaled down when _not_ logged in. This might be a bug though.

Eleganta said:
Request,
width: 100% height: auto CSS for non-logged in users.

Why it is useful,
I have to login to have images scale to my window size. For some reason - images to do not get scaled down when _not_ logged in. This might be a bug though.

Can confirm on Midori + Arch Linux x86_64. IMO scale-to-fit is probably the sanest default, but this depends on where the majority of non-logged-in e621 accesses are coming from. If they are mostly coming from phones or tablets, defaulting to 'reduced samples' would be more sensible.

I'm against having configuration/preferences for logged out browsing (this issue just came up in another thread); IMO that creates potentially confusing situations for anyone who browses both logged in and logged out at separate times. We should just pick a policy that is generally moderate and usable on all devices.

From Nimmy in the TWYS thread: "One day we'll hopefully have the ability to just lock specific tags on or off any submission, that would solve pretty much all problems we have with tagging disputes, and also reduce the number of records since people wouldn't be able ignore us anymore."

Is that possible in any way in relation to the current tagging system? Granting users of a certain rank the ability to lock tags would kill so, oh so many tag wars.

Would such a function require a revamp of the tagging system as it is right now?

Peekaboo said:
From Nimmy in the TWYS thread: "One day we'll hopefully have the ability to just lock specific tags on or off any submission, that would solve pretty much all problems we have with tagging disputes, and also reduce the number of records since people wouldn't be able ignore us anymore."

Is that possible in any way in relation to the current tagging system? Granting users of a certain rank the ability to lock tags would kill so, oh so many tag wars.

Would such a function require a revamp of the tagging system as it is right now?

Currently an individual post's tags are stored in the DB in a space separated list (pretty much exactly what you see when you edit a post), so locking a specific tag on it would probably require some really hacky code. :x

Then again, storing two separate lists then merging them might be another idea...hmm.

parasprite said:
Then again, storing two separate lists then merging them might be another idea...hmm.

Perhaps, under the Lock Rating button there could be a window for that, i.e
male on a separate line makes sure the male tag can not be removed.
-male on a separate line would make it so that the male tag can not be added to the post.

Peekaboo said:
Perhaps, under the Lock Rating button there could be a window for that, i.e
male on a separate line makes sure the male tag can not be removed.
-male on a separate line would make it so that the male tag can not be added to the post.

That's not a bad idea for the interface.

Now I just need to build the back end. :/

parasprite said:
Currently an individual post's tags are stored in the DB in a space separated list (pretty much exactly what you see when you edit a post), so locking a specific tag on it would probably require some really hacky code. :x

Weird, I thought another admin (tony?) had commented that that was just a cache, and they were also stored in the somewhat expected way -- (postid, tagid) table.

Anyway with what you are proposing, wouldn't you need three lists of tags, not two? Freely changeable tags, tags forced ON, tags forced OFF?

savageorange said:
Anyway with what you are proposing, wouldn't you need three lists of tags, not two? Freely changeable tags, tags forced ON, tags forced OFF?

I figured the male -male would only need one list.
Like the blacklist.
Though I'm probably misunderstanding the finer details of how the list would work.

Peekaboo said:
I figured the male -male would only need one list.
Like the blacklist.
Though I'm probably misunderstanding the finer details of how the list would work.

Not sure what you mean here. Is it 'the user entered male, but male is forced OFF?' If so, that is two lists (freely settable tags, tags forced OFF) that you need to store for that post.
To handle the case 'the user removed male, but male is forced ON', you also need to store a forced ON list for that post.

In detail:

• The user enters whatever tag changes
• They submit the form -> changes are sent to the server
• The system reads the list of tags provided by the user
• It reads the list of forced OFF tags for that post
• It reads the list of forced ON tags for that post
• Forced ON tags are added to the user-submitted tags if not present
• Forced OFF tags are removed from the user submitted tags if present
• The list of 'all tags currently applied to this post' is updated in e621's database, from the thus-adjusted list of user submitted tags.

(you can see here that I made a slight error before. You need 'all tags currently applied to post' , ie. exactly the list Parasprite stated is already present, rather than 'freely changeable tags'.)

I should point out again that I have little internal knowledge of e621's system; that's why I asked. The implementation I described is one that seems efficient and minimal from my outside perspective.

savageorange said:
Weird, I thought another admin (tony?) had commented that that was just a cache, and they were also stored in the somewhat expected way -- (postid, tagid) table.

Looks like you're right, I had no idea that existed. That actually helps explain a few unrelated things I've noticed.

This might not be as complicated as I thought. :D

parasprite said:
This might not be as complicated as I thought. :D

"Might this be the end of tag wars?
Turn in in 2016 to find out!"

Requested feature: When a higher res version of a picture is uploaded, translation notes should be transferred and ,if the post was in a pool, the new picture should be swapped with the deleted picture in the pool.

Why it would be useful: 2 months ago a user uploaded post #748316, a higher res version of post #551604. They didn't add the translation notes or add it to the pool. I just fixed it, but in order to do this I had to:

• Know it was a higher res of a deleted post
• search status:deleted parent:748316
• Go to the note history and use my knowledge of Japanese to match up the Japanese text with the translations
• Add the notes
• Set the pool to active
• Add the new pic to the pool in the correct spot and remove the deleted pic.

This was only possible because I knew it was a higher res of a deleted pic from a pool, and knew enough Japanese. I'd imagine this type of situation almost always gets resolved when both pics are still active, but even then it could be a lot of steps, especially if there were multiple pictures.

Deh-tiger said:
Requested feature: When a higher res version of a picture is uploaded, translation notes should be transferred and ,if the post was in a pool, the new picture should be swapped with the deleted picture in the pool.

Why it would be useful: 2 months ago a user uploaded post #748316, a higher res version of post #551604. They didn't add the translation notes or add it to the pool. I just fixed it, but in order to do this I had to:

• Know it was a higher res of a deleted post
• search status:deleted parent:748316
• Go to the note history and use my knowledge of Japanese to match up the Japanese text with the translations
• Add the notes
• Set the pool to active
• Add the new pic to the pool in the correct spot and remove the deleted pic.

This was only possible because I knew it was a higher res of a deleted pic from a pool, and knew enough Japanese. I'd imagine this type of situation almost always gets resolved when both pics are still active, but even then it could be a lot of steps, especially if there were multiple pictures.

That's why everyone should use forum #87369
It copies all notes from the old post to the new one, adjusting the note sizes and positions to the new image dimensions
And it posts as the first comment:
Bigger version of post #1234

Requested feature: ability to follow artists/tags, and have a list within a page on the my account section with new posts for that artist/tag.

Why it would be useful: saves the trouble of searching the artist/tag and can show multiple artists/tags easily in one section.

Other similar sites already have this feature, so it seems appropriate to have it here.

xXMAGIKzMushroomXx said:
Requested feature: ability to follow artists/tags, and have a list within a page on the my account section with new posts for that artist/tag.

Why it would be useful: saves the trouble of searching the artist/tag and can show multiple artists/tags easily in one section.

Other similar sites already have this feature, so it seems appropriate to have it here.

We actually do have a feature for that, but it's only priv+ currently. I'll bring this up with the others to see if we might be able to work something out for members.

parasprite said:
We actually do have a feature for that, but it's only priv+ currently. I'll bring this up with the others to see if we might be able to work something out for members.

Yep, funny timing, I just found that feature. Like you said, I can't use it though. Thanks anyway.

parasprite said:
We actually do have a feature for that, but it's only priv+ currently. I'll bring this up with the others to see if we might be able to work something out for members.

I've been trying to get in good graces to earn a rank up to unlock subscriptions myself.

Furrin_Gok said:
I've been trying to get in good graces to earn a rank up to unlock subscriptions myself.

Ah, I'm not the only person who wants this feature then.

Requested feature: A (View tag edits) link next to the Posts section on the profile page, specifically limited to edits on your uploads, in order of recency.

Why it would be useful: Educating uploaders on tags they forgot to include on submissions, as well as keeping tabs on potential tag vandalism

↑ I second this

Feature request: Additional screen and warning for reporting comments older than 1 month.

Why it would be useful: Cut down on useless tickets.

Requested feature: Use brackets when searching for tags
Why it would be useful: Instead of something like

-dragon -male

searching for posts that don't have either the dragon OR male tags, you could use

-(dragon male)

to exclude posts with both dragon AND male tags, but still show posts with only one of the tags.

Lance_Armstrong said:
Feature request: Additional screen and warning for reporting comments older than 1 month.

Why it would be useful: Cut down on useless tickets.

Everything about this. +1

personman444 said:
Requested feature: Use brackets when searching for tags
Why it would be useful: Instead of something like

-dragon -male

searching for posts that don't have either the dragon OR male tags, you could use

-(dragon male)

to exclude posts with both dragon AND male tags, but still show posts with only one of the tags.

I like it. :)

+1 to parenthetical searching. A search for "cat -(dragon male)" is equivalent to a search for "cat" with "dragon male" in the blacklist, so I think this would be relatively easy to implement.

Tags starting ( would probably need to be removed/fixed in that case.

(I think most of the tags in the above search are mistakes anyway. there are a few artist tags that aren't.)

Some of the artists would be hard to tag after such change (･3･), but it would definitely cut down the number of mistags.

Just look at these. Would be nice if we didn't have to clean up those all the time.

leomole said:
+1 to parenthetical searching. A search for "cat -(dragon male)" is equivalent to a search for "cat" with "dragon male" in the blacklist, so I think this would be relatively easy to implement.

Not easy due to a number of factors (string parsing can be really tricky, and parentheses are already used in tag names) but it's something we've been wanting to do for a long time.

TonyLemur said:
Not easy due to a number of factors (string parsing can be really tricky, and parentheses are already used in tag names) but it's something we've been wanting to do for a long time.

What about brackets ([]) or braces ({})?

It seems like the easy way out would be to require a space on the inside of the parens: "cat -( dragon male )"

Also if we're doing this I'd really like a better OR feature, like the one Derpibooru has. Being able to search for something like (A || B) && (C || (D && -E) || F) would be nice.