[kronolith] Event notification from another user private calendar

[Jens Wahnes]

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.

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?

> 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']")


Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.horde.org/archives/kronolith/attachments/20160218/d79fbd55/attachment-0001.bin>