Trunk build 2003-03-12: WinXP, Mac 10.1.5 Overview: Create a new profile, open the address book and it creates a Collected Address Book. Expected Results: Since the mail preferences no longer point to the Collected Address Book (CAB) by default then it should not be created in new profiles. Now the auto collection feature points to the PAB instead. Note: Bug# 196926 mentions this issue.

Marking nsbeta1 because we should not create address books, by default, that are not needed.

Mail triage team: nsbeta1+/adt3

taking

This patch removes the forced CAB from the address book & related code. For new profiles the CAB will no longer be created. For existing profiles, I've added code so that if ldap_2.servers.history.dirType doesn't exist, but history.mab does, it will automatically add the CAB back into the preferences. As address book won't create a history.mab file by any other means, then this should be sufficient. Of course, if a user reverts to a previous version of address book & then comes to the later one then the CAB will have been recreated - but there's nothing sensible we can do about that. David, could you check that the palm sync code still works with this change as well please? (I've patched the file, just can't test it...) Thanks.

Mark, getting rid of the collected ab for new profiles will be really helpful. But, at first look, I think this is overly agressive about removing the backend code that protects the collected AB from being deleted. For existing profiles with a history.mab, or profiles where the user has selected an AB other than the personal ab for CAB, I don't see why losing that protection is useful. That being said, since the user can pick any AB to be their CAB, I'm not sure all that protection code is correct, since at least some of it seems to just look for history.mab...thoughts?

(In reply to comment #5) > But, at first look, I think this is overly agressive about removing the backend > code that protects the collected AB from being deleted. For existing profiles > with a history.mab, or profiles where the user has selected an AB other than > the personal ab for CAB, I don't see why losing that protection is useful. That > being said, since the user can pick any AB to be their CAB, I'm not sure all > that protection code is correct, since at least some of it seems to just look > for history.mab...thoughts? > I mainly went agressively so that we could remove as much "old" stuff relating to the CAB as possible, rather than always having it hanging around. It would also fix bug 171125 where uses would like to be able to delete the CAB. Having said that I can understand your concerns. Currently we provide a differently worded dialog for deleting an address book that is not being collected into and one that is see: http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/resources/locale/en-US/addressBook.properties#73 and the line below. If I recall correctly, then we should clear the collection pref if we delete the address book to which we collect addresses. So we do have some protection, which I agree is very limited and just to the UI. The question would be, how much protection for the book to which we collect addresses do we want to enforce? I certainly think anything we do include should be driven from the mail.collect_addressbook pref and not history.mab. We have some part of the UI covered (which may or may not be enough) should we also somehow enforce extensions to ensure what happens wrt the address book to which we collect? or leave it to the authors?

Mark, is this patch still valid and what you want to do? If so, let me know, and I'll review it again.

Comment on attachment 210069 [details] [diff] [review] Remove the forced-CAB options v1 (In reply to comment #7) > Mark, is this patch still valid and what you want to do? If so, let me know, > and I'll review it again. > David, see the comments on mozilla.dev.apps.newsgroups. I think we're going to completely rework what we do on this, so at the moment, I think its best to cancel the review until we sort out what we are really doing.

thx, that was indeed the impression I got from the newsgroup.

We don't want this at the moment, we'll probably be revisiting it in TB.next.