Hi Salvis,
At this point I'm trying to figure out how much of an overhaul, and the liabilites it would have to...
Have Taxonomy subscriptions be sent only when a term is chosen from two separate vocabularies...
I.E. 1 vocabulary is for locations... 1 Vocabulary is for categories...
Meaning they would *only* get an email when *both* terms are chosen from the two separate vocabularies...
Is this even possible as a plug in, or would the whole subscriptions_taxonomy module have to be hacked...
My only other option is to list all of the categories over and over again beneath each city resulting in a redundant vocabulary consisting of 1,000,000 plus terms... and at this point taxonomy is completely timing out at 50,000 terms...
in anticipation...
Daryl
Comments
Comment #1
salvisActually, it should be very easy, thanks to hook_subscriptions_queue_alter(). If your event carries a node, you can inspect the node and discard the event (set it to NULL), if it doesn't meet your conditions.
Comment #2
Daryljames commentedwould you be interested in doing a paid modification?
Comment #3
salvisContact me through my contact form.
Comment #4
wim leersSubscribing. I want to know if this works out or not. (Daryl is a client of mine.)
Comment #5
salvisAfter giving this some more thought there's one thing that I don't quite understand yet: who is doing the choosing? Please make a concrete example of what kind of subscriptions you expect people to enter, and what kind of posts they should and should not receive.
Comment #6
Daryljames commentedWe have 2 user roles buyer, and seller... buyers post requests for things they would like to buy... Sellers subscribe to the categories that they sell in (1 vocabulary) and their location (another vocabulary) when a buyer chooses matching terms on the node/add form from both vocabularies then the seller gets a notification...
The subscribed party should receive notification of all posts from the allowed content types that meet this criteria...
Comment #7
salvisPlease give me a concrete example, something like "John is a seller and wants to sell a bike; he selects 'bike' and 'Kalamazoo'. Any buyer who has subscribed to both 'bike' and 'Kalamazoo' will get a notification."
Is that what you need?
Comment #8
Daryljames commentedJohn has a business... he sells bikes... for his subscription he selects bikes from the *category vocabulary*, and Kalamazoo from the *location vocabulary*...
James is looking to buy a bike... he posts a new node, and selects bike from the *category vocabulary*, and Kalamazoo from the *location vocabulary*... John receives a notification...
But if James where to select Bikes, and New York... John will *not* get a notification of the request for a bike quote...
In other words it's an all or nothing type of setup... If the terms from *both* vocabularies do not match, then no notification is sent...
p.s. sorry for the delayed responses I haven't been able to get online till really late at night...
Thanks
Comment #9
salvisOk, now I understand. This does not seem to need any user interface, does it?
Your two vocabularies are unlikely to change, so two (named) constants in the code for the two vocabulary IDs would be sufficient customizability, right?
Comment #10
Daryljames commentedWe are using heirarchical select for the user interface... and all we're doing is adding another vocabulary so no it shouldn't need any UI...
As we grow, we will be adding more *terms* and possibly changing the *terms* of the vocabularies... But we can name the vocabularies *Category* and *Location* and leave them that way if need be.
Comment #11
salvisOk, then we can settle for the two vocabulary IDs (vid's in the {vocabulary} table). That leaves you free to change the vocabulary names, add/change terms, whatever.
Just in case you have other vocabularies and/or kinds of subscriptions, for example a vocabulary "Music", would you want to have notifications about Location and Music blocked (because they have Location but not Category) or delivered (because they have Music)?
Comment #12
salvisThis never got off the ground...
Feel free to reopen if there's still interest.
Comment #13
tignux commentedI'm interested in this kind of customization. Anyone can help me?
Comment #14
tignux commentedI'm strongly interested on this feature
Comment #15
Daryljames commentedwe ended up using views saved searches and notifications modules
Comment #16
salvisThis is an old issue and an exotic feature (two people in three years).
I don't think it makes sense to put this into Subscriptions itself, but it would make sense in a little custom add-on module.
Feel free to reopen if you want to work on it and discuss it.