Re: Event notification from another user private calendar

Michael J Rubinsky wrote:

> Quoting Jens Wahnes <[email protected]>:
>
>> On Tue, Feb 16 2016, at 11:49:41 -0200, Luis Felipe Marzagao wrote:
>>
>>> Em 15/02/2016 11:47, Luis Felipe Marzagao escreveu:
>>>> Hello:
>>>>
>>>> I´ve just been notified in kronolith (the orange bottom-right box)
>>>> about
>>>> an event that was created by another user in his private calendar.
>>>>
>>>> I do not have access to that calendar. It´s not listed in my shared
>>>> calendars.
>>>>
>>>> If I click on the event name at the orange notification box I get a
>>>> "Event not found" error (red box). Probably because I don´t have access
>>>> to that event, as expected, since it´s private for that user.
>>>>
>>>> We are using kronolith 4.2.14.
>>>
>>> Today it has happened again.
>>
>> I didn't notice this on our test server, but since we updated our main
>> server to the latest versions of Horde (including Kronolith 4.2.15),
>> this is happening to us as well.
>>
>> The problem seems to stem from the horde-alarms script being run (a
>> cronjob in our case). After the update, the horde-alarms script
>> consumes way more memory than before and takes ages to run (before:
>> less than a second, after the upgrade: more than a minute).
>
> There was a bug in the code that polls each application for alarms. We
> weren't actually polling the applications at all in certain cases. This
> commit:
>
> https://github.com/horde/horde/commit/4b482074340bf4e7ddc469d69172c5c0a2c761f8
>
>
> fixed the issue, and probably explains the longer execution time, since
> each application is now actually polled. I'm not seeing your other
> issue, but will look into it further.

I did some testing with higher debug levels during a run of the 
horde-alarms script which generated a ton of output which I've been 
wading through.  One thing that caught my attention was a query that was 
logged and looks like this:

SELECT * FROM kronolith_sharesng WHERE share_name = 0 [pid 18524 on line 
321 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"]

Note that there is a zero as query parameter here. If you run this 
query, it returns the complete list of all shares (well, at least with 
MySQL), and if you suppose that the code now picks the first share_owner 
from that list, this might be the cause why the notifications a 
wrongfully assigned to the user with the lowest share_id in the 
kronolith_sharesng table.

This *might* be a happening only when there are "old style" share_names 
in the table, i.e. share_names that are equal to the user name of the 
owner of the calendar (equal to alarm_uid or share_owner for that 
matter) and not some random string as is the case nowadays for 
share_name.  I tried to fiddle around with this a bit to make certain, 
but it's hard to test without destroying data in the tables. Maybe it 
happens only if that user with the lowest share_id in 
kronolith_shares_ng also has got real entries in kronolith_events as 
well.  I can't really tell.

 From the logfile with the queries generated during a run of the 
horde-alarms script, I can also tell that the other (later) queries of 
the type

SELECT * FROM kronolith_sharesng WHERE share_name = ...

look OK, that is they have a user name (equal to the share name) there 
and not a zero, so this *might* have to do with some variable that is 
not initialized on the first time a loop is run.  This is of course only 
speculation, but it's hard for me to pinpoint the exact cause because 
the debug log file is huge and I don't really know what to look for.


Jens

-- 
kronolith mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]