[kronolith] Event notification from another user private calendar

[Michael J Rubinsky]

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

> On Wed, Feb 17 2016, at 12:08:53 -0500, Michael J Rubinsky wrote:
>
>> Quoting Jens Wahnes <wahnes at uni-koeln.de>:
>>>> Em 15/02/2016 11:47, Luis Felipe Marzagao escreveu:
>>>>> 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.
>>> 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 see. So this tells me two things:
>
> (1) The package that I would need to downgrade to get back the old
> behavior of horde-alarms (short runtime, low memory requirements) is
> Horde_Core. (In fact I downgraded to version 2.20.6 just to do some
> tests - it works.)
>
> (2) With that version of Horde_Core, running horde-alarms is
> more or less a no-op.

As far as applications other than "Horde" go, yes.

> Now I wonder: what have we been missing in the past with the
> horde-alarms script defunct? To my surprise, there *are* notification
> emails being sent from Horde even with horde-alarms completely
> deactivated. What does horde-alarms actually do that doesn't happen
> otherwise?

horde-alarms polls applications without the user being logged in.  
While the user is logged in, his/her specific alarms are determined.


>> I'm not seeing your other issue, but will look into it further.
>
> Thanks.  Maybe it depends on the authentication backend (LDAP in this
> case)?
>
> I also did another test, that is emptying out the whole horde_alarms
> table and then running horde-alarms.  As opposed to the old behavior,
> the entries in the horde_alarms table were re-created with the newer
> versions (where horde-alarms is no longer a no-op).  But even then,
> when starting with a clean table, the duplicate entries belonging to
> the user with the lowest id in kronolith_sharesng are still created.
>
> Another thing I noticed is that even for events that had previously
> been marked as "email notification sent" in the alarm_internal field,
> there are emails sent to the wrong user when the entry is duplicated.
>
> I also noticed that the link in emails sent by horde-alarms is wrong.
> It states <http://127.0.0.1/services/prefs.php?app=kronolith> instead
> of the actual URL which would begin with https at the very least. I
> suppose this means that I need to change $conf[use_ssl] and
> $conf[server][name] accordingly? (Currently, they are at their default
> values, "Attempt to auto-detect" and "$_SERVER['SERVER_NAME']")

Correct.


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/kronolith/attachments/20160218/b3d108f6/attachment.bin>