Seeing a few more hours left in the day, I started thinking about my proposed change to term_node, which would add a new "uid" column. The argument for it was, in a nutshell: * no duplication of data when the following occurs: * future possibility of "all users can tag any node" Besides the fact that I personally didn't /need/ the feature, I thought it was easy to code in, and provided a lot of future contrib possibilities. Because of this, I fought against questions by jbond and killes regarding "well, can't you just use node.uid to determine 'My Tags'?" I'm now leery on moving forward with this addition. It's a tricky bug, so I'll sum it up here: * administrators should be able to do everything. * administrators will not be able to delete an /individual/ uid's entry in the term_node table. the only solution would be a whole new set of UI screens. The problem isn't the INSERTs or backwards compatibility. Easy as pie. The big problem is that, on node save, the taxonomy code deletes all assigned nid/tids in the term_data, and then recreates them fresh from the incoming $edit data. This is a sensible thing to do - I've used the same trick before. With the addition of the term_node.uid though, it becomes not only "what nid/tids do I delete?", but also "what uid's nid/tids do I delete?". And THAT's the big problem. You are a normal user with node create capability. You add a brand new node, and you add some new terms. Your uid is saved into term_node.uid with these tids. A day later, you go back and edit the node, tweaking the terms. Taxonomy.module deletes all nid/tids matching your uid from term_node. Taxonomy.module resaves your tweaked nid/tids with your uid. So far, no big deal. A uid-aware DELETE would be: DELETE FROM {term_node} WHERE nid = $nid AND uid = $uid; Now, assume for the moment: You are an administrator and you'd like to edit the node. The folksonomy input becomes prefilled with ALL tids assigned. You fix the whatever and you save the node. Hilarity ensues. At first glance, this seems to do the "right thing". Since you're a different uid than the normal user, the _save DELETE will delete all nid/tids associated with your uid (in the previous example, none, as of yet). As the node is saved, brand new nid/tids entries are added associated with your uid. From the perspective of the very first two bullets of this email, Everything Is Perfect: two uids have tagged a node independently of each other. Awesome! But, there are two big issues: * ALL assigned nid/tids are placed in the folksonomy input. * The administrator can not modify another uid's nid/tids. At first glance, the easy answer to the first bullet is "well, instead of getting all nid/tids and showing them, just SELECT based on the current uid". And, yeah, that's a proper answer for a multi-user installation, especially considering that 5000 users could give one nid 5000 unique tids, and that'd make a prefilled input pretty unwieldly. But that fix breaks an important tenet: "an administrator should be able to do everything." There'd be no way, without a new and scalable UI, for the admin to say "Normal user has screwed up, and I'd like to modify his, not my, terms for this node." Conclusion for step #1: node.uid is in, term_node.uid is out. This is still a teensy problem, because an admin could edit someone's node adding new tids, and the "My Tags" feature would be slightly incorrect ("hey! the admin added that tag! not me!"). But, "Tags Associated With Nodes I've Created" just doesn't have the same ring to it. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus