Using sep5 commercial trunk build related bugs: bug 41720, bug 97530 Another rename folder case which doesn't work: If you have a local subfolder (POP account folder or under Local Folders) specified as a filter destination and you rename the parent of the destination folder, the filter will not work and will disable on attempted firing. Steps: 1. In Local Folders, create a folder and a subfolder. 2. Create a filter for a mail account (either IMAP or POP) which specifies action as Move To Folder and select the local subfolder as the destination. Confirm OK from both filter rules dialog and the main filter dialog. 3. Send a message which will match the filter criteria, get the message and verify the filter is indeed working. 4. Rename the parent folder, leaving the subfolder name as is. 5. Send yourself another message which matches the filter criteria, get the message. Note is is not filtered as expected. Check the rules.dat and see the filter path shows the old name for the parent folder, check the filters ui and see the filter has been disabled.

To clarify: the rename parent situation is ok for imap destination folders -- the change path name is recorded in rules.dat.

I know there could be some problems with local rename because of rdf resource leaks.

The problem was that we were deleting the subfolders w/o creating new renamed ones. This is necessary because uri will change if parent is renamed. Also this patch includes the fix for bug 98470, where subfolders disappeared until you click on the twisty. The fix for this problem is to notify the addition of subfolders. cc bienvenu for review.

Is the whole purpose of adding RenameSubfolders so that we can track filter moves, and fix the twisty? It seems like there might be an easier way of doing that without changing so much code. But if not, what code is RenameSubFolder copied from? Why do you do a GetDatabase() after calling SetFlags()? Is there a reason, or was the code copied from somewhere else?

RenameSubfolders is needed because we have to recursively create subfolders i.e transfer subfolders from old folder to new folder The GetDatabase() and SetFlags call are needed so that the new sub-folder has correct flags and also for making it in sync w/ db and the summarycounts, We can avoid GetDatabase calls but we will have to depend upon the user to click the folders.

could you add a comment as to why GetDatabase() is called where it is and what it does? Otherwise, r=bienvenu

cc sspitzer for sr

sr=sspitzer. if you check in the call to GetDatabase() make sure to add a comment (like bienvenu requested)

fix checked in.

was this checked in for both trunk and branch?

I can't get this to work in today's branch build (all platforms). Will try the trunk, too.

OK, it's working on today's trunk build... are we going to have this for the branch? Added nsbranch keyword to get evaluation. Reopening to catch attention.

thanks laurel. this wasn't showing up on my radar because it was marked fixed. I'll add it to 99508 and take it to PDT today.

PDT+. Pls check it into today.

fixed on trunk

err, fixed on branch.

OK using sep24 commercial 0.9.4 branch build win98

Well, this has the same kind of problem we had in 97830. If I rename the parent folder then exit before getting another message, when I relaunch and get a message which matches the filter, the filter is disabled and message doesn't move and the rules.dat shows the old parent/path. So, scenario withing session works, exiting after rename parent doesn't work. I will double-check the exact destination folder as was bug 97830.

So, it's 98730 exactly... no matter what level, exact destination folder or parent, is renamed it will not be recorded properly in filters if you exit after rename. Reopen 98730 or this one?

Sorry, slip of the fingers... that last bug number should be 97530. And since it doesn't have the PDT+ (fixed trunk before branch), I'll reopen this one. I'll double check on today's trunk build, too

Marking this fixed again, we've decided to reopen 97530 since that more specifically describes the problem. Will wait for 97530 to test this one again.

Usin sep26 branch: Bug 97530 is now fixed and verified on the branch. Also revisited this rename issue and this bug is still OK on today's branch. Marking verified for branch. Even though I did some testing on trunk several days ago, I'll check again and on all platforms after branch release, so adding vtrunk keyword.

removing link to this fixed bug from mozilla 0.9.6 release notes.

Reopened... Using nov19 commercial trunk build: After renaming parent to filter destination folder I do not get any alert that associated filter(s) will be affected. Sending another message which matches the filter in the same session will result in an alert that the folder could not be found and filter(s) will be disabled. I even tried collapsing and expanding Local Folders after rename and before sending another message to try to force folder (changes) discovery. This parent scenario is not working properly.

Please set a new target milestone.

bug 120203 will fix this.

moving to 1.0.1

fixed

OK using feb 01 commercial trunk build: win98, linux rh6.2, mac OS 10.1