For the moment adaptor works we can see signal/slot.
I create operator << >> to add struct to dbus.
I didn't test if it will work with kolab (need to fix compile).
svn path=/trunk/KDE/kdepim/; revision=678380
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=/trunk/KDE/kdepim/; revision=665433
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
Merge local subscription support from proko2.
This allows you to use online IMAP for your mails and disconnected IMAP
for your groupware data on the same Kolab account.
svn path=/trunk/KDE/kdepim/; revision=642514
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
Frank Osterfeld
Laurent Montel
Till Adam
Thomas McGuire
Ingo Klcker
Pradeepto Bhattacharya
David Faure
Volker Krause
Pino Toscano
Stephan Kulow
Allen Winter
Mathias Soeken
Matthias Kretz
Aaron J. Seigo
Jaison Lee
Tom Albers
Reinhold Kainhofer
Dirk Mueller