JeffreyH> hey, that worked
<gbaillie> yo
<JeffreyH> amazing
<stearns> hiya
<JeffreyH> So, I'm working on bug 6702
<gbaillie> no soup :)
<JeffreyH> I thought I was done, but I realized I hadn't read the spec right
<JeffreyH> basically, getting read/unread working on recurring events
<JeffreyH> anyway, to make a long story short, it's desired that read/unread for recurring events apply to "all events that look the same (modulo recurrence-id matching dtstart)
<JeffreyH> but I lobbied for trying "read/unread/needs reply apply to all occurrences"
<stearns> so that says it's stored on the master?
<JeffreyH> which is much easier
<JeffreyH> well, in the end, yes, the "look the same" bit would've been a little complicated
<JeffreyH> not impossible, just not the place to start
<JeffreyH> so anyway, in the final analysis, what I'm trying to implement is
<JeffreyH> read/unread/needs reply apply to all occurrences
<JeffreyH> and the nicest way to do that is to make changes only apply to the master, never occurrences
<JeffreyH> so
<JeffreyH> that's working fine, no sweat
<gbaillie> what about modifications?
<JeffreyH> making a change to the master changes everybody now that attributes are inherited
<JeffreyH> for now, modifications, too
<JeffreyH> the problem
<JeffreyH> is that when a change is applied to master and it's inherited by lots of occurrences
<JeffreyH> that change doesn't result in UI updates
-->| reid[osaf] (n=rae@tnir.org) has joined #recurrence
* reid[osaf] is eavesdropping if that's ok