This ticket can be deemed no longer necessary in favour of https://git.cyrus.foundation/D86, T1104, T1105 and T1106.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 10 2016
The fix for this is in https://git.cyrus.foundation/D86
Mar 9 2016
It is the frontend that proxies a GETANNOTATION command to the backend, even though the original command is GETMETADATA.
Investigating where the issue is exactly.
Mar 8 2016
Accepted during yesterday's meeting.
Of course accounts can be of various granularity:
- there might be vanilla smtp or ldap accounts, that provide nothing else and require full configuration
- there might be a kolab account that comes with imap, smtp, ldap
- there might be a generic imap account that comes with imap and smtp.
- there might be a jmap account that provides everything but communications only over jmap
SMTP should be in Sink because:
- Access is backend specific
- smtp might be replaced with another mailtransport protocol (and the client shouldn't care). E.g. JMAP has a mechanism to send mail
- the sent mail folder is with the resource as well
- mailtransport may move to the server
- The outbox needs to be persistent, and browsable similarly to a folder
LDAP Should be in Sink because:
- Access is backend specific
- It provides contacts in addressbooks (just like a regular addressbooks), so we should have one query API.
- The configuration for ldap belongs to the same service.
Mar 7 2016
Fixed in kdepimlibs 4.13.0.9
Also reproducible on linux when using kontact and waiting for the message to arrive first.
The problem is probably with events automatically being added to the calendar (by wallace). MemoryCalendar::rawIncidences() yields a result, yet the event can't be found in mItemIdByUniqueInstanceIdentifier.
Akonadi::CalendarBasePrivate::item(const class QString &) const: Can't find any incidence with uid "22B992D0634043024F14DBC43D09B8CAD5-B49BE4C6D5B60918"
This means we are looking for the event B992D0634043024F14DBC43D09B8CAD5-B49BE4C6D5B60918 in storage collection 22, but apparently can't find it.
This has been fixed by not listening to the status but for the synchronizationCompleted signal. The script probably aborted prematurely.
This has been fixed by not listening to the status but for the synchronizationCompleted signal.
libkolabxml has been enhanced to detect invalid creation dates. Also, kolab-format has been enhanced to not write out objects that had an error during conversion.
The full message looks like this:
An event has been transformed with empty created date:
Confirmed to be a windows-only issue:
Mar 6 2016
Updating the ticket to reflect the new semantics.
@Adityab it's been a while now, could you let us know what your assessment is?
This was in Doing for Sprint 201609 but unassigned, and has no story points either?