[dev] Kronolith category/color patch, per user

[Kevin Myer]

Quoting Chuck Hagenbuch <chuck at horde.org>:

>
> Part of my resistance to this is that I can't see how the ability to
> know, from looking at an event and it's color, whose it is and whose
> category it is, will hold up beyond very small groups.

Having the ability to say, that, for example, all events on the organizational
calendar show up in "IU-blue", instead of white (if you don't have the same
categories as the organization calendar), or your own colors if you do, would
be one example.  You provide consistency by ensuring that the organization's
colors and categories are shown.  Think of it as a way of enforcing
brand-recognition...

The logic becomes, for a viewer of the event:

if (color == IUblue and category == IU and owner == IU) {
Its most likely an IU event
}

Currently, that logic is muddy, because color and owner don't come into play:

if (category == IU) {
switch:
case mine:
case someoneelse:
[it could be mine, if I have that category, or]
[it could be theirs, but their intention of using the category was totally
different than mine (or it could have the same meaning), but either way] color
== mine, or
default: color==default
}

The border enhancment helps distinguish between whether an event is mine or
someoneelse, but leaves ambigious whose event it is.

Incidentally, for the border class, using $event->getCreatorID() to determine
whether an event is mine or not breaks down, if someone else has write access
to your calendar and creates an event on it.  So, for example, a secretary
schedules a very important meeting for her boss, on his calendar.  Boss
consults his calendar for the day, sees the event isn't his and ignores 
it. Pandemonium breaks lose.

When I wrote my patch, what I did to get the color for each event was to
determine the calendar the event came from, then determine the owner of that
calendar.  What I'd think would be helpful would be to have a getOwner() call,
that would do just that - lookup the share its coming from and find out who
owns the share.  Because Owner != CreatorID, in some cases, as I found out (I
didn't miss any meetings, thankfully, because I noticed it for past events,
when reviewing behavior on a test install).

What I ended up doing here was updating to Kronolith 2.1 and merging my
color/category patch with that.  Wasn't too painful, and I'll just end up
maintaining a local patch.  Although I still think that having a horde
preference would provide a meaningful choice: 'shared_categories', true, or
false, if true, categories are treated as shared across the installation,
meaning the current behavior, or false, meaning display each user's
colors/categories in the legend and on the calendar :)

Off the top of your head, are there any specific dependencies that Kronolith
HEAD has on Horde HEAD?  I need some of the additional features in Kronolith
2.1 (specifically the static FBUrl and the additional info provided in 
the body
of email messages, for mail clients that don't support iTip) but I don't want
to run a production Horde install on a full Horde HEAD snapshot, if I can get
away with just snapshotting Kronolith.  Nothing has broken yet in 
Kronolith and
the code changes seemed to be fairly minor, with some desirable enhancements,
but...

Thanks for all the work on Kronolith (and Horde too).  It has really matured
into a viable calendaring solution :)

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org