Re: Event notification from another user private calendar

Quoting Luis Felipe Marzagao <[email protected]>:

> Em 18/02/2016 18:31, Michael J Rubinsky escreveu:
>>
>> Quoting Jens Wahnes <[email protected]>:
>>
>>> 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"]
>>
>> This is probably coming from Kronolith_Application::listAlarms().
>>
>> As an admin user, execute the following from the admin phpshell page,
>> using kronolith's scope:
>>
>>

>>
>>
>> You should see an array of share_names. If I'm right, one of these will
>> be '0' for some unknown reason.
>
> Yep, for me it does. The 23th item:
>
> array(24) {
>   [0]=>
>   string(23) "0ZiHPQiFsvBP6PWQoSL0iwA"
>   [1]=>
>   string(32) "11e3b9f2f49fab07664945d4cede8469"
>   [2]=>
>   string(32) "57f3b572c7d8276e65b91e3cd346b172"
>   [3]=>
>   string(32) "5bdc6fa2c97cecef501b34c47c14d9f9"
>   [4]=>
>   string(2) "ac"
>   [5]=>
>   string(4) "acfs"
>   [6]=>
>   string(13) "Administrator"
>   [7]=>
>   string(3) "aps"
>   [8]=>
>   string(3) "cel"
>   [9]=>
>   string(3) "daa"
>   [10]=>
>   string(2) "em"
>   [11]=>
>   string(23) "FmzDcAiFsvBP1WO3OgIwOPA"
>   [12]=>
>   string(23) "f_B_EAlE4RdL8ZGJ9IzxuQ5"
>   [13]=>
>   string(3) "ibl"
>   [14]=>
>   string(4) "lfbm"
>   [15]=>
>   string(3) "mes"
>   [16]=>
>   string(4) "rabm"
>   [17]=>
>   string(5) "rabmj"
>   [18]=>
>   string(4) "robm"
>   [19]=>
>   string(23) "SZtmkeuHIuoMv74QHovb1A1"
>   [20]=>
>   string(4) "veri"
>   [21]=>
>   string(4) "vmlr"
>   [22]=>
>   string(3) "vsg"
>   [23]=>
>   int(0)


This means that the share in the database doesn't have a share_name  
for some reason. Can you see which share that is in the  
kronolith_sharesng table?


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject

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