Two changes pushed to master

ellie timoney ellie at
Sun May 15 20:25:12 EDT 2016

> For the first time in a while, EVERY Cassandane test should be passing.

I'm still (just now) getting failures from Carddav.sharing_samedomain
and Carddav.sharing_crossdomain:

I dug into these a bit on Friday afternoon, and in both cases the return
from GetAddressBooks() didn't include the shared addressbook, so the
assert_deep_equals would fail.  I imagine (but haven't verified) that
the same thing is happening now too.  Any ideas?

On Sat, May 14, 2016, at 11:23 PM, Bron Gondwana via Cyrus-devel wrote:
> I've just pushed two changes to master along with some Cassandane tests. 
> For the first time in a while, EVERY Cassandane test should be passing.
> One of the commits fixed the JMAP code to match the new scheduling
> changes, so those tests pass again.  It now handles the Schedule-Address
> header, or reading from the existing spool record - and sets the spool
> records correctly too.
> The other is a massive rewrite of mboxlist_findall to return a 'struct
> findall_data' - which includes the extname, the mbentry, the mbname, and
> the "category".  I think I've shown Nicola some of this, and I'll be
> showing her some more of it as we update the FastMail docs to match.  In
> summary, I've moved every folder that can't exist in Alt Namespace into a
> magic toplevel name which defaults to 'Alt Folders'.
> internal | normal | old altnamespace | new altnamespace
> | INBOX | INBOX (noinferiors) | INBOX
> | INBOX.INBOX | <invalid> | Alt Folders.INBOX
> (noinferiors)
> | INBOX.INBOX.sub | <invalid> | INBOX.sub
> | INBOX.inbox | <invalid> | Alt Folders.inbox
> | INBOX.inbox.sub | <invalid> | Alt Folders.inbox.sub
> Folders | INBOX.Alt Folders | Alt Folders | Alt Folders.Alt
> Folders
> Users | INBOX.Other Users | <invalid> | Alt Folders.Other
> Users
> And you can dot-stuff as many "Alt Folders" as you like :)
> So everything is representable in a reversible way inside Alt Folders. 
> You still get the "No Inferiors" appearing on a single folder, but it's
> not the top level INBOX.  For people living entirely in Alt Namespace, it
> will all make perfect sense.  For people crossing between the two
> representations, sure things get weird - but it's explainable weird.
> This isn't going to FastMail production straight away - I'm reverting it
> again on our branch until we have a launch plan - but there's the new
> code!
> One warning for users: it gets called with the 'data' parameter NULL on
> every change between namespaces, so make sure your callees check for
> NULL.  Most of them just if (!data) return 0; at the top, but the smarter
> ones can do thing like reset their internal childinfo state, because you
> can never have parent/child relationships across the namespace boundary
> :)  That's the main point of doing it, because otherwise INBOX would look
> like it had children in Alt Namespace even if it didn't!
> Bron.
> -- 
>   Bron Gondwana
>   brong at

More information about the Cyrus-devel mailing list