Bug 2382 - folderitemrc not updated when account name is changed
Summary: folderitemrc not updated when account name is changed
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Folders (show other bugs)
Version: 3.7.9
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2011-03-17 17:39 UTC by Denis Laxalde
Modified: 2011-04-15 18:54 UTC (History)
0 users

See Also:


Attachments

Description Denis Laxalde 2011-03-17 17:39:55 UTC
It seems that the file folderitemrc is not updated when an account is renamed. Old account names still appear in this file, which disable all previously defined folders attributes.
Comment 1 users 2011-04-08 18:57:35 UTC
Changes related to this bug have been committed.
Please check latest CVS and update the bug accordingly.
You can also get the patch from:
http://www.colino.net/claws-mail/

2011-04-08 [colin]	3.7.8cvs75

	* src/account.c
	* src/folder.c
	* src/folder.h
	* src/folder_item_prefs.c
	* src/folder_item_prefs.h
	* src/prefs_account.c
		Fix bug #2382, "folderitemrc not updated when account
		name is changed". Indeed, this wasn't done.
Comment 2 Denis Laxalde 2011-04-15 18:19:34 UTC
While the patch indeed fixes the problem, I find the new behaviour quite surprising. Actually, the folderitemrc is not stricto sensu *updated*. Instead, now, once an account is renamed, one full entry per folder in the account is added to folderitemrc and previously defined entries are not deleted. Yet previous settings are migrated to new entries.

This is quite confusing, at least for my use case. I typically have a few folder settings defined such as:

  [#imap/account1/folder1]
  newmailcheck=0
  [#imap/account2/folder1]
  enable_processing_when_opening=1

With CM 3.7.9, if I rename account2, the latter entry will remain and new entries for *each folder* in account2 will appear with all default values set, which just clutters up my (previously minimal) folderitemrc file…
Comment 3 Colin Leroy 2011-04-15 18:54:12 UTC
Indeed, but that's another bug of a lesser severity :)

Note You need to log in before you can comment on or make changes to this bug.