we realized it has to be done in kmail; can't be done in the kolab resource,
since there might be none instanciated when syncing the modified folder.
svn path=/branches/proko2/kdepim/; revision=352960
and then successfully synced to the server. This will be used by the kolab2
resource to trigger a free-busy update for this folder.
svn path=/branches/proko2/kdepim/; revision=352794
* Fix recognition of standard groupware folders for the case where we used
the wizard to set it up (folder known before the inbox exists)
* Preserve unknown subtypes (e.g. mail.drafts etc.)
Part of https://intevation.de/roundup/kolab/issue406
svn path=/branches/proko2/kdepim/; revision=350906
* write to KConfig as soon as it's changed, since some code calls readConfig on all
folders when creating a new resource folder (hmmm...)
[Till: I have the feeling mStatusChangedLocally is subject to this bug too]
* ignore subtype when the folder obviously can't be a standard resource folder for us
(as happens with shared folders) (https://intevation.de/roundup/kolab/issue406)
* don't overwrite existing annotations when syncing finds a shared folder
(the fix for this uses an internal "FROMSERVER" value)
* skip annotation stuff for noContent folders (https://intevation.de/roundup/kolab/issue429)
svn path=/trunk/kdepim/; revision=349982
* write to KConfig as soon as it's changed, since some code calls readConfig on all
folders when creating a new resource folder (hmmm...)
[Till: I have the feeling mStatusChangedLocally is subject to this bug too]
* ignore subtype when the folder obviously can't be a standard resource folder for us
(as happens with shared folders) (https://intevation.de/roundup/kolab/issue406)
* don't overwrite existing annotations when syncing finds a shared folder
(the fix for this uses an internal "FROMSERVER" value)
* skip annotation stuff for noContent folders (https://intevation.de/roundup/kolab/issue429)
svn path=/branches/proko2/kdepim/; revision=349982
Fixed the way the "standard groupware folders" are found when using the kolab xml storage:
instead of finding them by name, look for annotations like "event.default".
Fixed up mAnnotationFolderType and mAnnotationFolderTypeChanged, so that they
are only updated once we know if a folder is one of the standard groupware folders.
When the annotation isn't found and we try to create the folders, first check
for an existing folder with that name, and if it exists, change its contents type.
[This will happen to any existing proko2 user: you'll see a request for creating
the groupware folders, which will in fact only set the correct annotation on them]
Moved annotation values into kmailicalifaceimpl's array because one day Till
will need them from kmfolderimap :)
svn path=/trunk/kdepim/; revision=349074
instead of finding them by name, look for annotations like "event.default".
Fixed up mAnnotationFolderType and mAnnotationFolderTypeChanged, so that they
are only updated once we know if a folder is one of the standard groupware folders.
When the annotation isn't found and we try to create the folders, first check
for an existing folder with that name, and if it exists, change its contents type.
[This will happen to any existing proko2 user: you'll see a request for creating
the groupware folders, which will in fact only set the correct annotation on them]
Moved annotation values into kmailicalifaceimpl's array because one day Till
will need them from kmfolderimap :)
svn path=/branches/proko2/kdepim/; revision=349069
CVS commit by tilladam:
Aaaand, dimap mail eater number two for today. This time we prevent it
eating everything but the inbox on prefix changes, like so:
- have a bunch of folders at top level, because your prefix is INBOX
- change prefix to nothing
- sync
- all top level folders are removed locally since the server doesn't
list them anymore. They have an imap path, so we figure they must have
been on the server at some point, so that means we must have deleted
them locally, which means we need to delete them on the server
- add list of folder under the new prefix
- go through list of locally deleted folders (or those we think we deleted)
and deleted them from the server
- say hello to Mr. INBOX, the lonely inhabitant of your account since all
other folders have been removed
David's patch, I just figured out what happens.
svn path=/trunk/kdepim/; revision=347966
eating everything but the inbox on prefix changes, like so:
- have a bunch of folders at top level, because your prefix is INBOX
- change prefix to nothing
- sync
- all top level folders are removed locally since the server doesn't
list them anymore. They have an imap path, so we figure they must have
been on the server at some point, so that means we must have deleted
them locally, which means we need to delete them on the server
- add list of folder under the new prefix
- go through list of locally deleted folders (or those we think we deleted)
and deleted them from the server
- say hello to Mr. INBOX, the lonely inhabitant of your account since all
other folders have been removed
David's patch, I just figured out what happens.
svn path=/branches/proko2/kdepim/; revision=347963
- sync folder
- refresh cache (without clearing uid map)
- sync, during refresh, list all mails in folder, they are wrongly
considered locally present -> no download
- folder is empty locally
- sync
- folder is emptied on the server, since the mails that were supposed to be
there locally are not -> they must have been deleted
- make unhappy face because of mail loss
svn path=/branches/proko2/kdepim/; revision=347897
such as annotation support. Now only the dcop interface extensions and the
kolab resource itself which uses them are missing.
svn path=/trunk/kdepim/; revision=346738
- don't touch mLastUid when updating the uidMap
- only update mLastUid when loading from disk cache on startup and
after the GET_MESSAGES phase has successfully completed
- with mLastUid from last sync, upload new messages, don't change it
- list messages on server, if below (old) mLastUid and not present,
delete on server, otherwise if present locally (we just uploaded it), do
nothing, else download it
That should take care that messages which have ids between the mlastUid we
have and the highest uploaded one are downloaded, even if they were added
after our own upload (concurrent uploads), and it moves the two intermingled
issue of determing locally deleted versus new on one hand and determining
locally present and uploaded versus new on the other hand into separate
checks, namely uid <= mLastUid and uidMap.contains( uid ).
svn path=/trunk/kdepim/; revision=338793
- don't touch mLastUid when updating the uidMap
- only update mLastUid when loading from disk cache on startup and
after the GET_MESSAGES phase has successfully completed
- with mLastUid from last sync, upload new messages, don't change it
- list messages on server, if below (old) mLastUid and not present,
delete on server, otherwise if present locally (we just uploaded it), do
nothing, else download it
That should take care that messages which have ids between the mlastUid we
have and the highest uploaded one are downloaded, even if they were added
after our own upload (concurrent uploads), and it moves the two intermingled
issue of determing locally deleted versus new on one hand and determining
locally present and uploaded versus new on the other hand into separate
checks, namely uid <= mLastUid and uidMap.contains( uid ).
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=338792
- don't touch mLastUid when updating the uidMap
- only update mLastUid when loading from disk cache on startup and
after the GET_MESSAGES phase has successfully completed
- with mLastUid from last sync, upload new messages, don't change it
- list messages on server, if below (old) mLastUid and not present,
delete on server, otherwise if present locally (we just uploaded it), do
nothing, else download it
That should take care that messages which have ids between the mlastUid we
have and the highest uploaded one are downloaded, even if they were added
after our own upload (concurrent uploads), and it moves the two intermingled
issue of determing locally deleted versus new on one hand and determining
locally present and uploaded versus new on the other hand into separate
checks, namely uid <= mLastUid and uidMap.contains( uid ).
svn path=/branches/proko2/kdepim/; revision=338792
although I'm not sure why mContentsTypeChanged is true for michel and not for me.
Anyway this check looks more correct: it's now the opposite of the check before
setAnnotation().
svn path=/branches/proko2/kdepim/; revision=329967
o don't upload the local message flags of a folder unless at least the
status of one message was changed. If one did change, we must suppose to
know better than the server and upload. Otherwise the server is always
right.
svn path=/trunk/kdepim/; revision=329279
(the symptom was a "could not list folder foobar, no such folder" error box).
Strange that I didn't see that one before (probably the imappath was reset?)
svn path=/branches/proko2/kdepim/; revision=324884
(the symptom was a "could not list folder foobar, no such folder" error box).
Strange that I didn't see that one before...
svn path=/trunk/kdepim/; revision=324882
Store per-folder storage format in kmailicalifaceimpl and in a specific group of kmailrc.
Create groupware folders with the English names always, and set a translated label on them
(when using the xml storage)
svn path=/branches/proko2/kdepim/; revision=323018
Better handling of errors during "check uid validity". If it failed, and the
user chooses Continue, don't do anything relating to the messages, since it
will wipe them out (probably due to writeUidCache()), skip directly to doing
the acl stuff, then the subdirs. (kolab issue101)
svn path=/branches/proko2/kdepim/; revision=322438
user chooses Continue, don't do anything relating to the messages, since it
will wipe them out (probably due to writeUidCache()), skip directly to doing
the acl stuff, then the subdirs.
svn path=/trunk/kdepim/; revision=322436
* Store contents type on server using a "set annotations" job. Currently using /comment,
since imapd doesn't support /vendor/* yet. Discussion is under way.
svn path=/branches/proko2/kdepim/; revision=321827