Comparing the XHR data between v2 and v3 is very interesting.

They both have the exact same request URL, for example 
https://webmail.domain.com/SOGo/so/u...@domain.com/Calendar/eventsblocks?sd=20160731&d=20160903&view=monthview

However, the JSON data is structured differently and very incomplete between 
the two versions.  Because the SQL queries are also the same, and both return 
the exact same information (from the SQL debugging), there must be some sort of 
major change in the way that data is processed.  Which, in our case, removes 
95% (or more) of the existing calendar data before sending the JSON data to the 
client.

Any of the developers have insight on what could be causing this, or any 
further troubleshooting steps?

~ Laz Peterson
Paravis, LLC

> On Aug 20, 2016, at 7:47 AM, Laz C. Peterson (l...@paravis.net) 
> <users@sogo.nu> wrote:
> 
> I should also add that these calendar events do not appear in both the web UI 
> and also the CalDAV client.
> 
> As said before, the SQL queries are pulling 100% of the records, same as in 
> SOGo v2, but that data is not being 100% parsed or processed.  Something 
> seems to be “disqualifying” some of these calendar entries from being served 
> out by SOGo.
> 
> I wish I could offer more information — please tell me if there is a specific 
> troubleshooting I can do to help.
> 
> Thanks Ludovic.
> 
> ~ Laz Peterson
> Paravis, LLC
> 
>> On Aug 19, 2016, at 3:27 PM, Laz C. Peterson (l...@paravis.net 
>> <mailto:l...@paravis.net>) <users@sogo.nu <mailto:users@sogo.nu>> wrote:
>> 
>> Hello there Ludovic,
>> 
>> There are actually no errors at all, even with debug mode on.
>> 
>> What has changed with the SQL select statements between SOGo 2 to SOGo 3?
>> 
>> For one of these calendars in question, we have hundreds of events in there 
>> just this year alone.  But SOGo 3 does not actually show any events for this 
>> year.
>> 
>> The SQL query that loads this data which is not shown pulls up 49 rows that 
>> should appear in the August calendar.  But not one item is shown.  The same 
>> query in SOGo v2 pulls up the exact same 49 rows of data, and all items are 
>> shown in the calendar.
>> 
>> I don’t have much to go with here aside from that — there are no apparent 
>> errors in the logs.  Could the SQL results possibly have an item missing 
>> that SOGo v3 requires to place them on the calendar that SOGo v2 does not?
>> 
>> ~ Laz Peterson
>> Paravis, LLC
>> 
>>> On Aug 19, 2016, at 12:05 PM, Ludovic Marcotte (lmarco...@inverse.ca 
>>> <mailto:lmarco...@inverse.ca>) <users@sogo.nu <mailto:users@sogo.nu>> wrote:
>>> 
>>> On 2016-08-19 10:59 AM, "Laz C. Peterson" (l...@paravis.net 
>>> <mailto:l...@paravis.net>) wrote:
>>> 
>>>> When logging in as a specific user on SOGo v2, we get all expected 
>>>> calendar events.  At the same time, logging into the SOGo v3 server, only 
>>>> a fraction of those events are there — in some cases, there are no 
>>>> calendar events at all when we would expect dozens.
>>> Any errors in the sogo.log file for these users and calendars?
>>> 
>>> -- 
>>> Ludovic Marcotte
>>> lmarco...@inverse.ca <mailto:lmarco...@inverse.ca>  ::  +1.514.755.3630  :: 
>>>  http://inverse.ca <http://inverse.ca/>
>>> Inverse inc. :: Leaders behind SOGo (http://sogo.nu <http://sogo.nu/>), 
>>> PacketFence (http://packetfence.org <http://packetfence.org/>) and 
>>> Fingerbank (http://fingerbank.org <http://fingerbank.org/>)
>>> 
>>> -- 
>>> users@sogo.nu <mailto:users@sogo.nu>
>>> https://inverse.ca/sogo/lists <https://inverse.ca/sogo/lists>
>> 
>> -- 
>> users@sogo.nu <mailto:users@sogo.nu>
>> https://inverse.ca/sogo/lists
> 
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Reply via email to