* 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
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