Re: Event notification from another user private calendar

Quoting Jan Schneider <[email protected]>:

> Zitat von Jan Schneider <[email protected]>:
>
>> Zitat von 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"]
>>
>> We don't have any code that creates this query, I wonder where it's  
>> coming from.
>
> Actually we do, but in the SQL driver, while the query contains a  
> table name from SQLNG driver. This sounds like some mess-up.

Horde_Share_Sqlng extends Horde_Share_Sql. I don't see anything wrong  
with that query being executed for a Sqlng backend. It's the fact that  
the share name is '0' when Horde_Share_Base::getShare() is called that  
is questionable.


>
>>> 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/
>
>
>
> -- 
> Jan Schneider
> The Horde Project
> http://www.horde.org/
>
> -- 
> kronolith mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: [email protected]



-- 
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]