This behaviour is new since the 9.1 update, and is quite annoying for collecting purposes.

Example: I am on a character who is a blacksmith and miner. I go into Elwynn Forest. My zone list now tells me that there are vendors selling the recipes for the Blue Linen Robe and Blue Linen Vest in the zone (which is true), despite the fact that I am not a tailor and cannot learn these (and it's not looking at alts, since all my alts on that server and account know these recipes).

This appears to happen for all BoE recipes, again regardless of your alts being eligible or not.

Asking again, do you have Account Mode enabled or not? Send your settings screenshot, please.

I did not have account mode on - the only thing I can think of is if the "Ignore BoE/BoA Item Filters" functionality has changed since last patch, since that was checked both before and after.

Yes, Ignore BoE/BoA Item Filters affects this as per description ...if you want to ignore...profession requirements.... So yeah I think it was just broken before. 2.3.4a was the last broken version, 2.3.5 was fine (the first version with 9.1 content).

9f3af9f is the commit that changed the behaviour.

Personally, I think it's working as intended now. I suppose we could split that toggle into two, one being for recipes and one for everything else. But with our limited resources it might be pretty low on the backlog.
@ImUnicke, ideas?

I definitely understand the problem of limited resources, but I absolutely hope that you can find the time to split the checkbox behaviour up into two as this fix has (at least for me) created a drop in the overall user experience. It hasn't ruined the addon by any means, I'm not going to be a doomsayer or anything, but it is going to be a frustration in any zone with at least one boe recipe.

Why aren't you tracking recipes account wide if you are ignoring filters for BoE things? I suppose there's probably some way to have this niche situation accounted for, but it's a little strange to me. You're basically saying "I will collect every recipe on this character (technically accomplished via switching professions and keeping ATT's cache of learned recipes)" but then also saying "don't filter things that this character cannot collect" and that second option is making those recipes show.

Tracking recipes account wide means I will get into the following situation:

I have two different characters on different servers. Character A is a horde blacksmith on realm X, and Character B is an alliance blacksmith on realm Y. With account wide recipe tracking active, Character A won't see a recipe they would be able to obtain and learn if character B knows it, as account wide tracking will hide it. This goes against the goal of collecting as many blacksmithing recipes as I can on both character A and character B without also seeing a bunch of blacksmithing recipe on character C (an alchemist) even if both character A and character B know it.

Ok I thought about this more last night, and I think I understand the intent and issue and how to solve it.

'Ignore filters for BoE' basically turns any BoE/BoA into 'Account Mode' specifically for each individual Thing. So if that Type of Thing is not being 'Collected Account-Wide' then it makes no sense to treat it as being in Account Mode. This has often been a problem with Quests since they are such a nuisance.

In fact, I think that 'Recipes' is the only Type of Thing where a BoE of that Type is not always collectible Account-Wide (like Tmog/Mounts/etc.) and thus leads to your issue.

So basically the fix would be to ignore the 'Ignore Filters for BoEs' when the Type of Thing is not being collected Account-Wide, and determining the most efficient way to perform that logic. So hopefully sometime soon I can look into that change.

Thank you. =) That is indeed essentially the problem.

I see how this got broken now. Previously, it was actually doing as expected in this situation because the Bind on Pickup was returning as 'BoE' when collecting Account-Wide, but returning nothing when not Account-Wide. But I changed other logic to more accurately determine whether something is BoP by requiring that it identifies itself as BoP... so by returning 'nothing' the intent of a 'pretend' BoP recipe was in fact still acting as BoE for the other filtering.... whew. Complicated situation fixed by literally adding "or 1" into the code.

I'm glad the fix was simple, at least. =)