was changed locally, but nothing else, the "status changed locally" flag
was not set, and the status changes thus lost on sync.
svn path=/branches/kdepim/proko2/kdepim/; revision=426420
SVN commit 424289 by tilladam:
Don't use KIO::del to delete the local cache when removing a dimap
folder. The underlying KMFolderMailDir does unlinks, to avoid a storm of
progress dialogs, so let's rely on that.
svn path=/branches/kdepim/proko2/kdepim/; revision=424380
is quieted.
* Delay/compress UpdateCounts in FolderTree.
With this improvements,kmail don't eat the 100% CPU when refresh the cache from
a dimap server when this resides on the same lan.
svn path=/trunk/kdepim/; revision=405858
annotation for folders that show up on the server suddenly (for example
when you sync a fresh client to an existing account) are fetched as
expected. That prevents varied unpleasantness and constipation.
svn path=/branches/proko2/kdepim/; revision=401778
attempt to set annotations such that we can be sure the folder already
exists, when we check. This is only relevant if the first listed folder
with sufficient permissions is a newly created one. In most cases that
first folder will be INBOX, so mostly that will be used, but let's be safe.
Also make sure that "/" (the account root) is not used a a folder to check
for annotatability, as that always fails (which was the real bug).
CCMAIL: martin.konold@erfrakon.de
svn path=/trunk/kdepim/; revision=401649
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.
svn path=/branches/KDE_3_4_BRANCH/kdepim/; revision=395820
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
(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.
Kolab issue678.
svn path=/branches/proko2/kdepim/; revision=395795
"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
not syncing up of those labels. Make sure that in case of circular
renaming (A -> B -> A) the change is reset and the rename is possible.
svn path=/branches/proko2/kdepim/; revision=387070
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
The new name is saved to kmailrc so it is used when restarting kmail even thought the server still says INBOX.
https://intevation.de/roundup/kolab/issue619
But that's only true for cached-imap, I'm not sure how things work with online-imap or even other types of accounts.
Should we fix it for all types of accounts, or enable renaming-of-system-folders only for dimap?
CCMAIL: kmail-devel@kde.org
svn path=/branches/proko2/kdepim/; revision=380089
- 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
* Trigger kolab-freebusy-updating when changing the value of the incidences-for setting,
as Steffen pointed out.
svn path=/branches/proko2/kdepim/; revision=365950
shared by other people) in their own language. If someone from japan
shares their default Calendar folder with me, I'll see it as:
/user/Hirohito/Kalender, if I'm german. Solves proko2 issue530.
svn path=/branches/proko2/kdepim/; revision=364183
Instead of new signal, we emit "subresourceDeleted + subresourceAdded". It's necessary
to reload all incidences to make them readonly (or readwrite), anyway.
svn path=/branches/proko2/kdepim/; revision=360065
("Generate free/busy and activate alarms for: nobody / owner / all readers of this folder")
* New annotation jobs that can get and set multiple annotation entries (one after the other)
* Storage of incidences-for in KConfig, and using an annotation
* Added a combobox in the folder properties dialog, tied to the contents-type combo when it exists
svn path=/branches/proko2/kdepim/; revision=358234
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
Till Adam
Mario Teijeiro Otero
David Faure
Carsten Burghardt
Andrew Coles
Stephan Kulow
Ingo Klcker