Wrong indication of read/unread messages

afischer

This Bug is very annoying. When can we expect a fix for this?
Is it possible to downgrade to the latest working version (8.6.9)?

Best regards,
Achim

genesis74

Indeed the problem still persists. The only way I can get rid of those unread flags is:

kopano-admin --reset-folder-count <user>
kopano-srvadm --clear-cache all
mark all messages as read with IMAP client
restart kopano-server

It took several iterations of the above mentioned procedure with decreasing numbers of unread-flagged-messages before I managed to have all messages flagged as read via IMAP as well as WebApp. I found no way to manage this without an IMAP client.

fbartels

Hi @afischer,

I have just now uploaded the same build that we run internally to https://download.kopano.io/supported/core:/pre-final/
This has a “fix” for emails being truncated after searching for them. the downside of this change is that even though these emails are not truncated any longer, they will only load as plain text.
at least on my test system I was still able to observe the mails being shown as unread and up until know I am still missing information to reproduce the missing webapp settings, so this is probably still in there as well.

@genesis74 you steps seem a bit overkill to me. What I could observe (since I have my WebApp usually instructed to not automatically mark mails as read) is that when WebApp prefetches the message or when I click on the message it turns to read. meaning that the message are actually stored as read on the database only that webapp does not realise it at first.

afischer

Hello Felix,
Hm, we did not notice the problem you fixed. (truncated emails)
Our users, especially my boss, get impatient due to the bug of unread messages. I don’t want to install a beta-version with potentially new bugs, in which this annoying bug still exist.
But you don’t answer my question if there is a way to downgrade to 8.6.9
Best regards,
Achim

fbartels

@afischer said in Wrong indication of read/unread messages:

But you don’t answer my question if there is a way to downgrade to 8.6.9

I have not tested this myself, but our support has some experience in this area. I’d recommend to talk to then.

genesis74

Hi @fbartels,

I am not sure about your last sentence. Because it seems to me that this is the point - message state “read” is not stored in the database because after logging out of WebApp and logging back in (see my first post) or after restarting kopano-server messages that had already been flagged as read are marked as unread again.

By using IMAP as a second way to accessing the database I experienced that some of those messages appear as unread also in my IMAP client after doing the kopano-admin --reset-folder-count step. It made me believe that the “read”-state might have been written to the cache but not to the database (assuming WebApp and kopano-gateway/IMAP are not using the same cache or at least not in the same way).

genesis74

Hi @fbartels ,

my observation is as described in my first post. Especially after restarting kopano-server the unread-flagged messages turn up again. But sometimes also after logging out of WebApp and logging back in. The number of unread messages in the folder is then often inconsistent with the number shown next to the folder name. And all this is inconsistent with what I see if I use an IMAP-client. The only way I found to get this into line is what I described in my last post - yes, it looks like overkill, but it was the only solution I could find.

By the way - reading your last sentence I am a little bit in doubt if the database is updated correctly when marking those emails as read. In that case, clearing the cache should solve the problem completely, shouldn’t it? It seems to me as if the problem is that sometimes the new state of the read/unread flag is only saved to the cache but not the database …

fbartels

@genesis74 said in Wrong indication of read/unread messages:

I am a little bit in doubt if the database is updated correctly when marking those emails as read

yes, that is the current theory. we have multiple tables with similar data (e.g. properties, mvproperties, tproperties) there seems to me a mismatch there.

8GM-DK

Adding my voice here to confirm that the issue is also affecting us as well as (at least) one of our customers. We tried updating to the latest (ubuntu) final (core, webapp, z-push…) but it did not help.

8GM-DK

FYI: We could fix the issue with

kopano-admin --reset-folder-count $USER

It seems the cache is confused, and just clearing it did not help. This command updated the folders correctly.

fbartels

Hi @8GM-DK,

the above issue was addressed with the 8.7.1 release. please make sure to read the text above the changelog at https://documentation.kopano.io/kopano_changelog/kc.html#kopano-core-8-7-1-final-8-7-1-0 for further instructions.

8GM-DK

root@mail:~# kopano-dbadm kc-1444
Tue Jul  2 13:03:07 2019: [notice ] kc-1444: updating tproperties...
Tue Jul  2 13:05:13 2019: [notice ] kc-1444: updated 136 rows.
root@mail:~# kopano-admin --clear-cache=0x0020
The selected option is deprecated in this utility.
Forwarding call to: `kopano-srvadm --clear-cache cell`.
Error reading config file /etc/kopano/admin.cfg
[crit   ] Config error: Cannot normalize path "/etc/kopano/admin.cfg": No such file or directory

Hey @fbartels , ty for the information. The above happened when I tried to follow the instructions used in the changelog. I don’t seem to have a “admin.cfg”?

8GM-DK

I could remedy the situation by a simple

touch /etc/kopano/admin.cfg

Now the cache was cleared and it seems everything works as expected.