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

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

Saved Queries