Title: BTS activities for Thursday, May 07 2020
BTS Activities
Home page: https://sogo.nu/bugs
Project: SOGo
For the period covering: Thursday, May 07 2020
idlast updatestatus (resolution)categorysummary
4493
Thanks, indeed i didn't. I only run yum update sogo and called it a day...
Now it works
Il 07/05/2020 11:21, Ludovic Marcotte (lmarco...@inverse.ca) ha scritto:
On 2020-05-07 3:48 a.m., Cristian Mammoli (c.mamm...@apra.it) wrote:
Hi, after upgrading to 4.3.2 Contacts an Calendar don't work anym
HI, Andreas,
> On 7 May 2020, at 12:04, Andreas Blaha (andr...@blaha.at)
> wrote:
>
> Hi Patrik,
> this seems to have been fixed for the next release. I’ll give it a try as
> soon as the stable release is out.
Actually it was release 13 hours ago. I have already upgraded one of my
instances,
Hi Patrik,
this seems to have been fixed for the next release. I’ll give it a try as soon
as the stable release is out.
From: users-requ...@sogo.nu On Behalf Of Patrik Chadima
Sent: Tuesday, May 5, 2020 8:40 AM
To: SOGo reporter (flachape...@inverse.ca)
Subject: Re: [SOGo] Sieve filters sto
Hi!
On 5/7/20 10:52 AM, Christian Mack (christian.m...@uni-konstanz.de) wrote:
> SOGo uses the first email address it gets when looking up the user.
> As LDAP has no way of sorting or prioritizing multivalue attributes, the
> first one is random.
> So you can be lucky and it gets the one you want
On 2020-05-07 3:48 a.m., Cristian Mammoli (c.mamm...@apra.it) wrote:
Hi, after upgrading to 4.3.2 Contacts an Calendar don't work anymore,
in the logs I have tons of:
NAME:NSInvalidArgumentException REASON:EOKeyValueQualifier(instance)
does not recognize setValue: INFO:(null)
That's because
Hi, after upgrading to 4.3.2 Contacts an Calendar don't work anymore, in
the logs I have tons of:
NAME:NSInvalidArgumentException REASON:EOKeyValueQualifier(instance)
does not recognize setValue: INFO:(null)
With debug on:
sogod[19927:19927] PG0x0x55f3a5a32910 SQL: SELECT * FROM
sogo_cache_
Hello
Am 05.05.20 um 21:16 schrieb Stephan Jäkel (st...@rdev.info):
Hi!
I noticed some weird issue with RSVP's via CalDav.
A user gets an invite from a foreign system. When the user responds to that
request, the other
system receives a RSVP from one of the "aliases" the user has, instead of t