Page MenuHomekolab.org

Calendar folders appear to "disappear"
Closed, ResolvedPublic2 Story Points

Description

This ticket has originated with a installation using iRony 0.3.0 for CalDAV, backed by roundcubemail-plugins-kolab 3.2.3.

Either because of a former version or the current (latest) version of the software, a situation has been created in which a single folder has a /vendor/kolab/uniqueid metadata value in both the /private as well as the /shared namespace. Please note that, in addition, a /shared/vendor/cmu/cyrus-imapd/uniqueid folder metadata annotation is available.

Neither of the (three!) uniqueid values appear in cache tables, arguably indicating an error in the software; which this ticket is here to track and have verified (using functional and/or integration tests).

If the existence of these (multiple, different) metadata values is not disruptive to the software's operations, this should be verified with a test.

If the existence of these multiple and different metadata values is disruptive to the software's operations, then either the "garbage" needs to be cleaned up (can this be done automatically and autonomously?), the software needs to consistently choose and operate on the most consistent value for its purpose (i.e. /shared/vendor/cmu/cyrus-imapd/uniqueid or /shared/vendor/kolab/uniqueid, in that order, but not /private/vendor/kolab/uniqueid which is valid only from one particular perspective), or reliably "fail & bail" with the appropriate logging (so that an operations team can clean up the garbage).

Details

Ticket Type
Task

Event Timeline

vanmeeuwen updated the task description. (Show Details)
vanmeeuwen raised the priority of this task from to 60.
vanmeeuwen changed Ticket Type from Task to Task.
vanmeeuwen added a subscriber: vanmeeuwen.

The functions get_uid() and set_uid() functions [1] are likely causes of the aforementioned discrepancy of folder metadata values in different namespaces.

get_uid() retrieves an item using an ordered list of preferred sources of the folder metadata, whereas set_uid() will (rather bluntly) set the second if the first one fails.

A UID however should never be in the /private namespace. Arguably this means another ticket against Cyrus IMAP (to enforce the namespace of the configured custom annotation correctly), and/or against pykolab's setup-kolab to correct the configured custom annotations if so at fault.

grote moved this task from Incoming to In Triage on the Product Owners board.Jun 18 2015, 10:49 AM
grote added a project: Restricted Project.Jul 15 2015, 2:11 PM
machniak added a subscriber: machniak.

The existence of this private annotation is not disruptive or I don't see how it could be. Also, you can't see these folder anotations in the cache tables probably because they are stored in memcache. Of course, Roundcube can be configured to store metadata in sql db.

Anyway, /private annotation should not be used and some tests created. I'll work on this.

machniak moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 20 2015, 11:42 AM
machniak edited a custom field.

We can't give a prio to cyrus uniqueid annotation. I've found iRony's Kolab/Utils/DAVBackend.php code which (beside unsused class constants) sets folder UID and, I assume, the DAV client expects the same UID to be used later. So, it looks like we need to check the /shared/vendor/kolab/uniqueid annotation first and fallback to cyrus annotation if it does not exists in get_uid().

In T491#8369, @machniak wrote:

So, it looks like we need to check the /shared/vendor/kolab/uniqueid annotation first and fallback to cyrus annotation if it does not exists in get_uid().

It should rather be the other way around, giving priority to the /shared/vendor/cmu/cyrus-imapd/uniqueid annotation, and only if it doesn't exist, set/use /shared/vendor/kolab/uniqueid.

In any case, however, setting and/or using /private/vendor/kolab/uniqueid should be prevented / considered invalid.

Agreed about the /private namespace. This is fixed by above commit. The problem is with priority of the other two annotations. As I said, iRony (actually only iRony uses these methods) depends on the fact that we can set a folder ID to defined value. So, if we set "kolab" annotation to something and the use "cyrus" annotation we have a problem. That's why I left the order as it was before. See the commit. Tell me if you see this different.

machniak moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 21 2015, 10:59 AM
machniak reassigned this task from machniak to vanmeeuwen.Jul 28 2015, 11:56 AM

Please, review.

vanmeeuwen added a project: Restricted Project.Aug 3 2015, 11:06 AM
vanmeeuwen moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Aug 3 2015, 11:14 AM
machniak closed this task as Resolved.Mar 30 2016, 9:11 AM