Tickets :: Comment on [#14259] Event notification from another user's private calendar

* Your Email Address
* Spam protection	Enter the letters below: .___.__ . .. ,.__ [__ \| \\ / \./ [ __ [___\|__/ \/ \| [_./
Comment	> Okay, I just realized my table kronolith_sharesng_users had two problems: > > > 1 - One row had a share_id which did not existed on > kronolith_sharesng table, but referring to a user_uid that did exist > on kronolith_sharesng (which, in the case, was my uid: 'lfbm') > > So it was really messing up the $shares variable from line 310 from > file Horde/Share/Sql.php, since it does not verify if the share_id > from kronolith_sharesng_users exists on kronolith_sharesng. > > The outcome is $shares array ends up with one last item that only has > perms, but not a share_id, share_name and so on. > > > 2 - One share_id that exists (and is used by a active user) on > kronolith_sharesng did not existed on kronolith_sharesng_users. I'm > not sure what was the effect it was causing (if any at all). > > > So after adjusting number 1 above, horde-alarms has stopped > duplicating entries with the wrong user_uid. > > As for number 2, I'm not sure yet if this will have any effect. > > As for why the share_id got messed up on kronolith_sharesng_users, I > think I'll never know. Maybe it was during db migration process. > Can't say. > > Anyway, I think this is not a bug, maybe the need for an enhancement, > if at all, in order to add some verification code to see if > $row['share_id'] actually exist on $shares before creating another > array element in it on line 310 from Horde/Share/Sql.php. > > Thanks! > >
Attachment
Watch this ticket

Saved Queries