[Tickets #1414] NEW: Add original owner's categories and colors to calendars

[bugs at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/?id=1414
-----------------------------------------------------------------------
 Ticket             | 1414
 Created By         | kevin_myer at iu13.org
 Summary            | Add original owner's categories and colors to calendars
 Queue              | Kronolith
 Version            | 2.0.2
 State              | New
 Priority           | 1. Low
 Type               | Enhancement
 Owners             | 
-----------------------------------------------------------------------


kevin_myer at iu13.org (2005-02-18 20:50) wrote:

One of the features lost in between the Horde/Kronolith ALPHA release and
the latest officially released versions was the ability to see the color of
a category, as a user intended it to be, for shared calendar.  In the
officially released version of Kronolith, only your colors and categories
are shown.  If another user has shared a calendar with you and uses the same
categories, your colors show on those categories.  If the category names are
different, the color goes to the default color.  I had posted to the horde
mailing list a few months back about a way to possibly remedy this, as I
think it severely limits the useability of any of the shared apps.  After
muddling along, I think I have a workable patch that provides a proof of
concept of what I'm after and it doesn't seem to break anything :)

Essentially, what I've done is created a new colors and fgColors function in
the Pref->CategoryManager class (horde-CategoryManager.patch).  These two
functions take one argument, an owner, and this allows lookup of categories
and colors for other calendars (and ultimately all shared items).  My
thought is that this could be further simplified if the existing color and
fgColor functions were modified such that by default, they looked up the
current user's categories and colors, but if an argument were specified to
the function, then they would take that argument to be the owner uid to
lookup the category and color for.

The second patch takes care of adding the logic to extract the owner
information about each event, so that colors and categories can then be
looked up appropriately.  Rather than assume that all colors and categories
are of the current user, each event has a lookup for the category and color.
 For each unique owner, and then category, an array is built, which is then
cycled through when the category legend is built.

End result is that at a quick glance of the legend, you can tell which
events are owned by a user (cued by color).  If an event is owned by another
user, but has the same category name as one of yours, you can still
differentiate between them.

Caveats:

I am not a programmer.  This is my best attempt to provide the answer to
Chuck's proverbial question - "Patch?".  It hasn't broken my system that a
few of us use as our primary mail and calendar client.  YMMV.

Things I know are flawed:
1)  I made the assumption that the CreatorID for an event == owner of the
calendar.  However, I later realized that if you give write permission to
someone else to your calendar, they get set as CreatorID.  What I really
need to do is get the information back about which calendar an event is on
and who owns that calendar.  But I'm not sure how to do that.
2)  Formatting of the patch is probably not up to the specs provided.  I can
clean it up if the idea is accepted - I want to make sure this is a viable
option before spending any more time on it though.

If these patches are accepted, I would think that modifying Mnemo and Nag to
do the same thing would not be too difficult.