Re: Event notification from another user private calendar
Michael J Rubinsky <[email protected]> Thu, 18 Feb 2016 15:31:32 -0500
| Newsgroups | gmane.comp.horde.kronolith |
|---|---|
| Message-ID | <20160218153132.Horde.kN1bXcs3kOyljzQcsdp6r0p@h4.theupstairsroom.com> |
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: var_dump(array_keys($injector->getInstance('Kronolith_Shares')->listAllShares())); You should see an array of share_names. If I'm right, one of these will be '0' for some unknown reason. > 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 -- 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]
smime.p7s
(application/pkcs7-signature, 5.6 KB) - not displayed