Recurring events are not working as expected. You have to tell the resource to decline them or double booking is possible. In third party clients like Outlook you won’t even notice that its double booked.
Im on 8.7.22 and tested it 5min ago.
it looks like the attachments are not yet completely on the new server, can that be?
just for the record. The export uses the stored rfc message if one has been generated. Which apparently has been the case on your old system. These messages are stored alongside the attachments so if there is a database reference to the message, but its actually not found on disk then what you have seen is the expected behaviour.
We switched over to a new encrypting method for files and that is the option for the new secret key
Make sure you have the latest config file that is supplied by kopano-webapp-plugins-files
Config file located is /etc/kopano/webapp/config-files.php
part of the challenge is that the code that evaluates rules is only part of the delivery component of Kopano and therefore cannot be interfaced with by other components. So one would need to reimplement the whole engine in e.g. php to make it usable from WebApp directly.
We actually had a prototype at some point for a daemon with a RestAPI that could take care of this. But it never progressed further.
If you would be a programmer, the easiest route for you would be to use python-kopano to connect to your mailbox directly. From there on you could use python to filter your mails and move them accordingly. I am not aware of an example here however.
That’s strange. I can not reproduce the issue.
Just for reference, the problem occurred with webapp 126.96.36.199+1967, then I upgraded it to 188.8.131.52+1995.1 but the blank messages were still present. I accessed Webapp with Firefox 87.0 with Adblock Plus enabled.
And now it’s the same browser, and the same version and the messages are readable, again.