under INBOX and those of others under the user namespace, prettify
the labels used in the resource view a bit.
Prokde35-z Item 2.
svn path=/branches/kdepim/enterprise/kdepim/; revision=709038
* Added support for finding Scalix groupware folders
* Added support for creating Scalix folders
svn path=/branches/kdepim/enterprise/kdepim/; revision=705754
This is the backend implementation of "incidencesFor", which was already in the folder dialog
("Generate free/busy and activate alarms for: nobody/admins/all readers"), so this is a bugfix,
since it makes that feature work as expected -- and since I won't get alarms set up
by everyone else at KDAB anymore :)
svn path=/branches/KDE/3.5/kdepim/; revision=665425
This also fixes a broken dcop-signal connect in the kolab resource since it was already updated to the new signal signature.
svn path=/branches/kdepim/enterprise/kdepim/; revision=665276
enterprise branch (actually it's even from the old proko2 branch). It allows
to exclude some folders from syncing, allowing you to use online and
disconnected IMAP on the same account for a disjoint set of folders.
The included changes for the Kolab wizard add an option to make use of this.
It will create an online IMAP account for mail folders and a (completely
hidden) DIMAP account for the groupware folders.
Approved by Ingo and Allen.
svn path=/branches/KDE/3.5/kdepim/; revision=649622
Don't list messages in the INBOX if it is the one of the groupware
main account and we are in "only groupware folders for this account"
mode. (proko issue 1207)
Merge SVN commit 531668 by tilladam from proko2:
Change the default for this back to true. (proko2 issue 1206)
Merge SVN commit 531683 by tilladam from proko2:
If we are hiding groupware folders, and the account is the groupware
base account, and it's set to only locally subscribe to groupware folders,
hide it completely from the folder tree. (proko2 issue 1207)
svn path=/branches/kdepim/enterprise/kdepim/; revision=642185
pre-condition:
two instances of the same event with two attendees in a folder which both
have access to and which they both use to store the event. This leads to
two events with the same uid, one of which has an internal uid, which is
used as the uid inside korganizer, to discern the duplicates. Let alpha
be the original event, and beta the copy, with the internal uid.
Here's what should happen:
1) user A changes beta and syncs it up
2) user B syncs, get's removal of old version of beta, which triggers
removal of the internal uid from the uid map
3) user B gets addition of the new version, with internal uid, add the
event again, with internal uid
But due to the bug this happens:
1) as before
2) user B syncs, but KMail signals deletion of event using uid, not
internal uid, thus internal uid is never removed from uid map
3) addition of new version of beta (with internal uid) triggers
conflict resolution, since internal uid is still in the map
Fix: parse kolab xml in KMail to find internal uid if present
and use it already at the stage of dcop signal emission.
(Kolab Issue 1298)
svn path=/branches/kdepim/proko2/kdepim/; revision=571107
base account, and it's set to only locally subscribe to groupware folders,
hide it completely from the folder tree. (proko2 issue 1207)
svn path=/branches/kdepim/proko2/kdepim/; revision=531683
performance bottleneck, and it's called in a tight loop for each loaded
incidence. Further step towards fixing issue 1118.
svn path=/branches/kdepim/proko2/kdepim/; revision=522435
accounts. This basically stores a blacklist of unsubscribed folders
(since we want new folders to show up, intially) per account, which is
persisted to kconfig. This list is used as a filter during folder
listing. Some heavy-ish refactoring of the subscription dialog to make
it extensible enough to allow reusing it for the user interface.
(proko2 issue 1095)
svn path=/branches/kdepim/proko2/kdepim/; revision=516320
kind, such that it is possible to trigger syncs from outside of KMail,
namely KOrganizer's resource view, via save.
svn path=/branches/KDE/3.5/kdepim/; revision=439727
Remove storage format and pending changes information of folder that are
deleted, or removed as part of a sync.
svn path=/branches/kdepim/proko2/kdepim/; revision=435420
if the foldertype in the config differs from what the message in KMail
contains, convert on write to the set format.
This is necessary as the resource has no way of knowing what the
old format of the incidence was, since only KMail has access to the
actual mail in the folder. That means that the resource has to
assume the folder's format is the incidences, when writing,
while the kmail end can recitify things in the mail when it sees
that mail contents and storage format do not align. In effect this will
result in incidences of one type in folders configured to use the other
one being converted if they are edited. As long as they are not edited,
nothing changes, reading is transparent.
This also fixes the problem of ical incidences in xml folders suddenly
losing their payload on change and being replaced with a crippled
xml-style mail.
svn path=/trunk/KDE/kdepim/; revision=434018