[kronolith] Event notification from another user private calendar

[Jan Schneider]

Zitat von Jens Wahnes <wahnes at uni-koeln.de>:

> Michael J Rubinsky wrote:
>
>> Quoting Jens Wahnes <wahnes at uni-koeln.de>:
>>
>>> 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"]

We don't have any code that creates this query, I wonder where it's  
coming from.

> 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



-- 
Jan Schneider
The Horde Project
http://www.horde.org/