> 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: https://paste.fedoraproject.org/366966/63357613/ 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 > user.foo | INBOX | INBOX (noinferiors) | INBOX > user.foo.INBOX | INBOX.INBOX | <invalid> | Alt Folders.INBOX > (noinferiors) > user.foo.INBOX.sub | INBOX.INBOX.sub | <invalid> | INBOX.sub > user.foo.inbox | INBOX.inbox | <invalid> | Alt Folders.inbox > user.foo.inbox.sub | INBOX.inbox.sub | <invalid> | Alt Folders.inbox.sub > user.foo.Alt Folders | INBOX.Alt Folders | Alt Folders | Alt Folders.Alt > Folders > user.foo.Other 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 > br...@fastmail.fm
