[drupal-devel] Core Folksonomy: Not Ready for term_node.uid?

[Morbus Iff]

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