Fix for deletion of folders with subfolders: those need to be removed first
(thanks Carsten for the hint). This is simply achieved by adding the imap paths
of all subfolders to the account's mDeletedFolders list, and at sync time,
asking the server to delete all those at the same time - in reverse order.
Till, Carsten: ok for backport?
svn path=/trunk/kdepim/; revision=395800
"incidences for annotation" combobox is properly enabled or disabled
depending on the folder type.
Also forward port the dimap folder renaming changes from proko2. Sorry for
mixing things here.
BUGS: 98784
svn path=/trunk/kdepim/; revision=388283
dialog and include it in the RMB menu of the foldertree. To make the check if the menu
should be shown a bit easier the folderstorage got a new "isMoveable()" function.
I noticed that moving of imap folders crashes again when the messages are moved (sigh)
but this is not related so I'll fix it afterwards.
svn path=/trunk/kdepim/; revision=385541
- try to add the message, find it incomplete
- trigger download
- upon download try to add it, strip the uid, because the target dimap
folder need to assign a new one on upload
- try to delete the message from the original folder which fails, since
we have no uid anymore with which to find the message
- add fails, because take fails, canAddMsg fails, try downloading again
- unfortunate loop and eventual crash
To remedy this I had to move the uid stripping down into KMFolderMaildir
where it clearly does not belong, because that is where the take() happens
which needs to know the uid. The real problem here is that the take should
happen on a much higher level, probably in the KMMoveCommand completion
handler and a copy should be added, not the message itself, followed by
deletion of the original.
svn path=/trunk/kdepim/; revision=368633
* Trigger kolab-freebusy-updating when changing the value of the incidences-for setting,
as Steffen pointed out.
svn path=/trunk/kdepim/; revision=365957
* 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
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
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
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
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...
svn path=/trunk/kdepim/; revision=324882
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
readwrite permissions on a folder which was initially readonly.
Outline setImapPath since I keep adding debug output to it and it's not speed critical :)
svn path=/trunk/kdepim/; revision=321373
the renaming happens in the foldertree immediately, but is stored in the account
(with persistence in kconfig) and done on the server at the next sync.
If that fails, the server is renamed back locally.
svn path=/trunk/kdepim/; revision=319628
Pass const QString& instead of QString& in the signal, when the caller isn't supposed
to change the value.
This showed an interesting issue in kmacctimap - the member vars were not needed,
and the clear() cleared the wrong one. All cleaned up (but please double-check).
svn path=/trunk/kdepim/; revision=314899