[Tickets #9657] Re: Categories / Tags Ignored

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/9657
------------------------------------------------------------------------------
  Ticket             | 9657
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Categories / Tags Ignored
  Queue              | Kronolith
  Version            | Git master
  Type               | Bug
  State              | Not A Bug
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2011-08-28 01:02) wrote:

> Since some of my users asked again for colored tags in kronolith, I  
> request this bug-report being changed to a enhancement request. Even  
> if it takes some time I believe it would be worth the effort to find  
> a solution for this.
>
> Would it be a possibility to colour events only if there is just one  
> tag assigned to it?

No. That would be confusing from a UI point of view. Plus, we are not  
going to color the event bubbles, they are already colored from the  
calendar's selected color. The only possible solution is to add small  
colored dots to the event bubbles for the event's tags (not the  
calendar's tags).

Are the performance implications that big in this
> case, also? Why is that so, if I may ask?

The performance implications are due to the fact that we have to query  
the tag backend once for each and every event that is to be displayed  
in the current view. It doesn't matter if the event is tagged with one  
tag or twenty.  It is for this reason we explicitly do NOT query the  
tag information for the calendar views. We can probably add a  
configuration switch to turn this off/on on an install-by-install basis.

We would also need a way to store (and hence query) the user's tag  
colorings, probably in the prefs system, since this information does  
not belong in the tagger backend.

I'll reopen this as an enhancement request, but I have no plans on  
working on this in the near future.