This leads to writing uninitialized data out (!) since readConfig hasn't read everything yet.
Tested changing the type of a folder and creating a new folder with a contents type, both work.
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=348874
isResourceFolder and hideResourceImapFolder into hideResourceFolder, since
the resource is not imap specific at all. Port all callers.
svn path=/trunk/kdepim/; revision=346967
of changing a folder to contain groupware data if hiding of groupware
folders is configured.
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=343821
correct to suppress the slash. Make the folderdia react correctly to failed folder-creations.
CCMAIL: 48080-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=322189
folder also in this folder" option I added a while ago. This page of the
folder properties still needs to be cleaned up, though.
I will buy several beers at aKademy for anyone able to come up with a
sensible name for this option which is shorter than 6 words or so and
understandable to users.
svn path=/trunk/kdepim/; revision=314280
(on the first OK the ACL tab needs to see isNewFolder, so set that to false
only when OK is aborted, not when the general tab asks for the folder to be created)
svn path=/trunk/kdepim/; revision=313196
(better than <foo.h>, especially when systems could have an identity.h somewhere)
A kconfig_update script moves the identities from kmailrc to emailidentities
svn path=/trunk/kdepim/; revision=311347
Thanks to Till for the advice on how to do that (storing folder id and using a KMMoveCommand)
Added kmkernel::findFolderById() to avoid copy/pasting yet another time
the code that looks in the 3 foldermgrs; ported the existing code to that.
CCMAIL: 43218-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=311024
Relying on local .uidcache file broke for noContent folders, but also, as I
just found out, for shared folders that you used to have permissions to, then lost
the permission, then got again (in such a case the old local uidcache does NOT mean
the folder should be deleted!!!)
svn path=/trunk/kdepim/; revision=309052
automatically created when someone else gives you read access to his inbox)
Don't show the ACL tab for noContent folders.
Fixed a crash
svn path=/trunk/kdepim/; revision=303903
for disconnected imap.
To share the code between the imap and dimap cases, a new job class MultiSetACLJob
can set and delete multiple ACLs one after the other. This makes me realize that
we should document more how one can write high-level Job subclasses (like
e.g. CopyJob and DeleteJob in KIO), it's very convenient.
svn path=/trunk/kdepim/; revision=303615
- added getUserRights() (and signal when received) to IMAPAccountBase
- store user rights in KMFolderImap and KMFolderCachedImap (my kingdom for a common base class!)
svn path=/trunk/kdepim/; revision=303360
* when creating a new folder, show the tab and get settings from parent (account and ACLs etc.)
* fixed progressbar that didn't get cleared up after the set/delete acl jobs
And KMFolderDia now doesn't close on error anymore (e.g. when trying to
create/rename a folder to the name of a folder that already exists).
svn path=/trunk/kdepim/; revision=303331
Testcase: create a child folder. Set expiry to 3 in parent, 10 in child,
reopen dialog for child: it showed 3 instead of 10.
... tempted to make a remark about whether that commit was tested or not :)
svn path=/trunk/kdepim/; revision=302921
from the general tab to the dialog itself. Should be a no-op, but will allow
using parentFolder for the ACL tab.
Tested against regressions with both ACL folders (existing and new) and local folders (ditto).
svn path=/trunk/kdepim/; revision=302919
ConfigModule (from configuredialog.*) as the base class.
This will make it possible to add a 3rd optional tab for ACLs.
This could also allow implementing an Apply button, but for this the code
for save() (was: slotOk) must be ready to be called multiple times, which I
guess isn't the case when creating a new folder.
svn path=/trunk/kdepim/; revision=301784
that was just created.
I considered popping up a nice little info box saying: "You just created
the bugger, how can there be a mailing list in there? There ain't even
mail in it.", but then decided against it because that would rob the user
of the experience of klicking on that button all night long wondering
why nothing happens. While they are doing that they are safely off the
streets and not exercising their (accidently bestowed) right to vote or
something.
CCMAIL: 77752-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=296316