it would be helpful if you would describe what problems with the calendar items you are experiencing.
crpb When i remove a Device in either the Web-UI or Admin-UI the Device wouldn't be listed in the Web-UI anymore but the Deviced ID is still listed in the Admin-UI without any other known facts.
Shouldn't those devices be removed from the Admin-UI aswell? I tried Refresh/Relog/Reboot in case of "Browser-Cache-Issues" :-).
Yes, they actually should be removed in the Admin-UI as well. We'll look into it. You have to be aware though, that simply removing device from a list doesn't prevent it from syncing again if the account is still configured on the device.
Is there a way to completely remove a Device from the System so any lingering state would be removed/purged and on the next connection from the Device it would have to do an resync? Something alike z-push's z-push-admin -a remove -d DEVICEID
That's what "Remove Device" in Mobile Devices in grommunio-web or Admin-UI actually do. They remove the state folder and force the device to resync.
crpb As i was trying to determine where to look i found the Redis-Cache for which i added a little function to my ENV just to get a quick overview - WIP...
First of all, grommunio-sync uses redis for interprocess communication states aka volatile states. It doesn't contain the actual sync state of the device which is saved in the user's store (sqlite).
crpb Is it safe to remove Devices from the cache?
What cache exactly do you mean? We do not recommend to perform any manipulation directly in redis as it might affect the performance of the system. If you remove some or even all keys, they will be rebuild again with time. There are fallbacks in the code if the data in redis is not available, so the sync itself should work, it just might be slower.
crpb Are their any states saved for the Devices in /var/lib/gromox/user/N/N i should be aware of?
grommunio-sync itself doesn't save any state information on the file system directly. Without going into details, technically all device sync states are under
/var/lib/gromox/user/N/N as grommunio-sync saves them in the user's store which in turn is a sqlite DB.
crpb How should i interpret KEYS in grommunio-sync:loopdetection? Those will be removed automagicallly after they have been dealt with?
Why do you need to interpret those keys? grommunio-sync will add, update or remove them if necessary.
The code block you linked to removes old search folders, so that they don't pollute the system unnecessarily.
crpb Could i just delete ALL Redis-Entries with something like redis-cli $(redis-cli KEYS grommunio-sync*) to remove all states so any Device would have to do a complete Resync?
You could delete all grommunio-sync related redis entries, but it won't force the resync of the devices as the sync states are saved in the user's store and not in redis.