On Wed, 16 Mar 2005, Morbus Iff wrote:
* 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.
I could use the feature.
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.
Well, it is a trick and nothing more. It has bugged many people over time. I suggest to rewrite it to act as follows: - a node it passed, it has a couple of tids attached (or not). - select all the tids that are attached to the node in the DB. - add those tids that were not there before. - remove tids that aren't there anymore. This uses some more db queries, but this is a non-issue since they are only executed on node_save.
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.
Not if rewritten as above. I assume that tids are still unique per node. [...]
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.
Not anymore. :) [...]
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.
You can easily make a list of all terms (maybe sorted by user) and a click on the one you want will remove that one (after confirmation). [...] Cheers, Gerhard