Eh, nevermind. I had already taken care of that. Fully fixed now with 
commits to both Nag and Core.

Changes have been made in Git (master):

commit 225ad4b21e00f639a9ec5723e98fd96bf67e640d
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu Jun 27 17:02:18 2013 -0400

     Don't filter on user when fetching related tags.

     Bug: 12405 Take shared resources into account as well.

  framework/Core/lib/Horde/Core/TagBrowser.php |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

http://git.horde.org/horde-git/-/commit/225ad4b21e00f639a9ec5723e98fd96bf67e640d

Partially fixed.

Tasks from shared task lists will now be included in the results. 
However, if a shared task is tagged with a tag that the user does not 
also use, the tag will not be included in the tag list at the top of 
the view.

Need to think about this some more. The problem is that objects are 
tagged by UID, which doesn't contain any information about the task 
list (or calendar, or ...) that the object belongs to. In order to 
include those tags, we need to remove the user filter. Unfortunately 
this will then include *all* tags on the system when no current tag 
search is in effect.

Changes have been made in Git (master):

commit 6a4e371c6951dc216b28f0da632a1786299f60a5
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu Jun 27 16:49:17 2013 -0400

     Bug: 12405 Don't restrict to current user when tag browsing.

  nag/lib/Search.php |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

http://git.horde.org/horde-git/-/commit/6a4e371c6951dc216b28f0da632a1786299f60a5

Working patch (but to be evaluated by a specialist !!!):

In nag/lib/Search.php, arround line 164, replace
  array('user' => $GLOBALS['registry']->getAuth()) array('xuser' => 
$GLOBALS['registry']->getAuth())

by

  array('xuser' => $GLOBALS['registry']->getAuth()) array('xuser' => 
$GLOBALS['registry']->getAuth())

This has the following effect:
In the Nagger.php code, the search function will not find the 'user' 
value in the filter array, and thus it will not filter on the user.

Regards,

Xavier

Further info:

- the link is located in the table rampage_tagged which stores the 
combination of user_id, tag_id and object_id. By switching the user_id 
in this table, I was able to get the other user to filter on it, but 
then the other user could not.
- by duplicating the records in rampage_tagged, I managed to get both 
users functionally filtering the correct records.

Hence, I see 2 possible solutions:
- the filtering code should NOT filter on the user_id, but rather on 
the tag_id and object_id.
- the rampage code that inserts into the rampage_tagged table should 
examine whether the object_id is in a shared task list, in which case 
other users should get their record added.

I think the first solution is by far the best one. The second could be 
a work-around one.

Xavier

Given a shared task list between 2 users (configured as a system list 
with the 2 users having full access to it).
User 1 defines a task in that task list with a new tag named "tag1".
User 1 then sees a button at the top of the task list to filter on the 
tag1 tag.
When user 2 logs on, the tag1 is shown alongside the task, but no 
filtering button appears.
User 2 then creates a task of himself in that list, using that same 
tag "tag1".
Then, the filter button appears at the top, but when activating the 
filter, only the task created by user 2 is shown, even if the other 
task from user 1 has that same tag. Moreover, if user 1 logs on again, 
he will see both tasks, both with the correct tag, but there again the 
filtering will only show his own task.

The rampage_tags and rampage_user_tag_stats tables indicate that only 
one physical tag entry exists with a unique id. But still the 
filtering differentiates for some reason between both users.

After some testing these are my preliminary conclusions:
- It is not important who adds the tag value, it is important who 
creates the task. If user 1 creates a task without any tag, and then 
user 2 edits the task to add the "tag1" tag, then only user 1 will be 
able to view the filtered entry. User 2 won't get to see it.
- The problem also occurs when using Filters with a tag filtering.
- I changed the nag_tasks owner field of a task (from user 1 to user 
2) but this had no effect on which of the users can filter it.

It is possible this problem goes beyond the scope of the nag 
application, eg. it could be that shared calendars have a similar tag 
filtering problem.

I could not find any work-around to get the desired behaviour (i.e. 
both users can use a common tag to filter all common tasks). If a 
work-around would exist, one could lower this priority of this bug.

Thanks!