Tickets :: Comment on [#12405] tag filtering does not work among shared task lists

* Your Email Address
* Spam protection	Enter the letters below: ..__ .__..__ . . \|[ __[__][__)\|__\| \__\|[_./\| \|\| \| \|
Comment	> 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!
Attachment
Watch this ticket

Saved Queries