smartIdentity: compare with existing Identities not working for me

[virtualid@…]

Thunderbird 3.0pre (20090917042833; Intel Mac OS X 10.5)

• Virtual Identity {dddd428e-5ac8-4a81-9f78-276c734f75b8} 0.6.0pre4

Hello,

In the case where I don't have a matching VIdentity in the RDF, it seems that VI can't find a match for my virtual identity.

I traced it back to the point where it wants to compare my virtual identity (email + smtp) with existing identities, and it fails because of comparison on the smtp key which is different (it is vI_useDefaultSMTP/(Default) for the virtual identity, which seems logical, and on my existing identities the smtp key is different / not default but set to a specific server)

If my problem is indeed real (and not caused by a misunderstanding of mine or a misconfiguration), I think one solution can be to enhance the method "equal" of "smtpObj" to take into account the case of the server being "Default" for one object, and in that case comparing instead the key of the actual default server. I don't have a specific implementation to offer as I don't know Thunderbird / Mozilla specifics, sorry.

In the attached file you can find my preferences + a debug log. I have hidden the email addresses, sorry.

[virtualid@…]

Preferences + Debug Log

[rene]

Hi,

thanks for the anaylsis and the suggestion. You are right, missed some implementation details while adding the switch to decide if SMTP should be stored.

Included the fix (close to the one you suggested) in 0.6.0pre5. Currently having no real internet connection I'm not able to test this implementation and really upload the changes into trac. This will happen tomorrow.

Please report if 0.6.0pre5 solves the problems. Nice regards, Rene

[rene]

diff from 0.6.0pre4 to 0.6.0pre5

[Ludovic LANGE <virtualid@…>]

Woah that was a quick answer...

Unfortunately I'm afraid that the fix is not enough - it still doesn't work for me.

(On a side note, you'll want to correct the link to 0.6.5pre5 : it is not pointing to the file which has a lot of underscores in it. You'll also want to add a .xpi extension instead of _xpi as it prevents the installation on my platform).

The problem with comparing this.keyNice to compareSmtpObj.keyNice (or this.key to compareSmtpObj.key) is best illustrated in my example :

• My default server is : key=smtp2, name=Pro
• The real identity is : fullname: Ludovic LANGE, email: ludovic.lange@…, smtpKey: smtp2, smtp: Pro
• The virtual identity is : fullname: Ludovic LANGE, email: ludovic.lange@…, smtpKey: vI_useDefaultSMTP, smtp: (Default)

Obviously, "(Default)" != "Pro" (and "vI_useDefaultSMTP" != "smtp2")

I think what we need to is :

1. Ask Thunderbird what is the Default SMTP ( here : smtp2 ), or maybe as a property of smtpObj : isDefault which would be true either if key == "vI_useDefaultSMTP" OR Thunderbird tells us that this is the default server (don't know how to check this, but obviously it is stored somewhere).
2. As a special case of "equal" between 2 smtpObj's, if both have "isDefault" to true, they are equal.

Thanks a lot for your work on this extension by the way : I can't live without =)

[rene]

Hi Ludovic,

I think the situation with the SMTP is a little bit more complicated, at least for me to find a clear and optimal decision.

For any permanently stored Identity, Thunderbird gives you the chance to store a dedicated SMTP or store none (== default == ""). If you stored none (==default) the global default Identity is used while sending.

Now, assume we decide that any vI-stored Default SMTP equals any current fixed SMTP, if the fixed SMTP equals the global Default one. We can't indicate the current SMTP now as Default, because it is a fixed one. And it will not be changed by any other tools or ways modifying the current Default SMTP. Until the message is going to be send, there is a difference between the Default SMTP (=="") and the to-be selected value of the Default SMTP of the current ID. Additionally it is a little bit difficult to decide which SMTP to store while sending the message.

To get rid of those problems and motivated trough the long-open ticket #110 I decided to let the user decide if the SMTP should be stoed at all. If you don't store the SMTP, there is no problem and no conflict with any existing SMTP.

Finally I think this is the option you require. Just remove the SMTP with the Data-Storage Editor (and/or deactivate saving of SMTP) and you should get what you like. Or am I missing some cases?

If you like to globally change all the stored SMTP value please check your profiles directory, make a backup of virtualIdentity.rdf and remove all "NS1:smtp="vI_useDefaultSMTP"" - entries in that file (while not running TB).

Hope that this solves your problems, please tell me what you think about this... Nice regards, Rene

[Ludovic LANGE <virtualid@…>]

Hi Rene,

I'm not sure I fully understand your answer... but the fact is that :

• I'm not using the "store SMTP option", as you can see in the dump of my preferences,
• The problem I'm facing is not a comparison between the "currently being created VI" AND "the VI's stored in the RDF", but really between the "currently being created VI" AND "all the fixed VI's of thunderbird" (those one belonging to accounts).

To make a long story short, I still face the problem and don't know how to solve it.

I will try something, can you tell me the bit of code needed to ask Thunderbird what is the currently selected SMTP server (which one is tagged "Default" in the list of SMTP servers in account settings) ?

Thanks for your help.

[rene]

Hi Ludovic,

now I got it. Thanks for insisting on it, problem is (hopefully) solved with [75b429e6c61] and released in 0.6.0pre7. There was a problem with the SMTP for smartReply Identitys, it was set to Default instead of Empty. Thanks for your ticket,

Nice regards, Rene

[Ludovic LANGE <virtualid@…>]

Hello Rene,

Thanks for hitting on this and coping with my insistance. However I'm afraid it still doesn't work for me.

Let me try to explain exactly what I see and why I think it doesn't work here.

Behaviour: When I hit the 'reply' button on an e-mail that was addressed to me (with my proper email address ludovic.lange@…, not a virtual one), the VI popups with a 'Choose a VI', which is to my opinion not the good thing to do : it should have detected that the "To:" e-mail is a real thunderbird identity.

Log Analysis: I see this in the log, which is a confirmation that it did not detect a match between the e-mail address and an existing thunderbird identity.

## vI_identityData: isExistingIdentity: Ludovic LANGE <ludovic.lange@XXXXX.fr> not found

It should have found it.

Debugging: I add a few debugging logs to vi_identityData.js, lines 101 and 106 to have a trace of the comparisons that are done (the number 0##, 1##,.. is the variable i, the number 0==, 1==, ... is the variable j) :

LLA:0## Comparing combinedName=Ludovic LANGE <ludovic.lange@XXXXX.fr>, smtp Key=vI_noStoredSMTP, smtp KeyNice=vI_noStoredSMTP, smtp Value= with account: account1
LLA:1## Comparing combinedName=Ludovic LANGE <ludovic.lange@XXXXX.fr>, smtp Key=vI_noStoredSMTP, smtp KeyNice=vI_noStoredSMTP, smtp Value= with account: account2
LLA:0== with identity: fullname=Ludovic LANGE, email=ludovic.lange@AAAAAAAAAAA.com, smtp Key=smtp1, smtp KeyNice=smtp1, smtp Value=Pro
LLA:1== with identity: fullname=Ludovic LANGE, email=ludovic.lange@BBBB.fr, smtp Key=smtp1, smtp KeyNice=smtp1, smtp Value=Pro
LLA:2== with identity: fullname=Ludovic LANGE, email=ludovic.lange@CCCCC.DDD.fr, smtp Key=smtp1, smtp KeyNice=smtp1, smtp Value=Pro
LLA:3== with identity: fullname=Ludovic LANGE, email=ludovic.lange@XXXXX.fr, smtp Key=smtp1, smtp KeyNice=smtp1, smtp Value=Pro
LLA:2## Comparing combinedName=Ludovic LANGE <ludovic.lange@XXXXX.fr>, smtp Key=vI_noStoredSMTP, smtp KeyNice=vI_noStoredSMTP, smtp Value= with account: account3
...

it should have a match on (i=1, j=3) because this is the (real) identity that we are talking about. But it didn't.

When I look at the test on line 106 :

				if (	(ignoreFullNameWhileComparing ||
					this.fullName.toLowerCase() == identities[j].fullName.toLowerCase()) &&
					(this.email.toLowerCase() == identities[j].email.toLowerCase()) &&
					this.smtp.equal(new smtpObj(identities[j].smtpServerKey))	) {
					vI_notificationBar.dump("## vI_identityData: isExistingIdentity: " + this.combinedName + " found, id='" + identities[j].key + "'\n");
					return identities[j].key;
				}

and the definition of smtp.equal :

	equal : function(compareSmtpObj) {
		if (this.key == null || compareSmtpObj.key == null) return true;
		return (this.keyNice == compareSmtpObj.keyNice);
	},

and the following log line :

...
LLA:1## Comparing combinedName=Ludovic LANGE <ludovic.lange@XXXXX.fr>, smtp Key=vI_noStoredSMTP, smtp KeyNice=vI_noStoredSMTP, smtp Value= with account: account2
...
LLA:3== with identity: fullname=Ludovic LANGE, email=ludovic.lange@XXXXX.fr, smtp Key=smtp1, smtp KeyNice=smtp1, smtp Value=Pro
...

it is obvious for me that the comparison won't be ok :

• fullName comparison is Ok (both full names are equal)
• email comparison is Ok (both email are alike)
• however SMTP comparison is not ok :
  • Neither SMTP key is null (so SMTP equal won't return 'true')
  • And the two KeyNice? don't match : "vI_noStoredSMTP" != "smtp1"

Here is mt proposal :

• We change SMTP.equal so that when one key is "vI_noStoredSMTP", the result is always true.

Here is the new equal function :

	equal : function(compareSmtpObj) {
		if (this.key == null || compareSmtpObj.key == null) return true;
		if (this.key == NO_SMTP_TAG || compareSmtpObj.key == NO_SMTP_TAG) return true;
		return (this.keyNice == compareSmtpObj.keyNice);
	},

With this patch, everything is fine for me. It correctly detects the existing identity when there is one, and popups when there is a virtual identity.

What do you thing of this approach ?

Thanks for your help.

[rene]

Hi Ludovic,

after your report I checked the SMTP-implementation again and found some bugs. Feels like the preview was more alpha than I liked. Thanks for your suggestion, you'r right. The comparison should return true if any SMTP.key is NO_SMTP_TAG. Beside, the key can't be null, therefore a the relevant line can be dropped ([ca29186cb18] and [61904f07193])

Thanks again for your deep investigation of the issue, please try upcoming pre8 and report if this solves the problems.

Nice regards, Rene

[Ludovic LANGE <virtualid@…>]

Hi Rene,

Indeed it works ! Good !

Thanks a lot for your hard work on this extension, which is very valuable for me.

Regards,

Ludovic.

[anonymous]

​decoration Changed 1 year ago by admin

​bathtub Changed 1 year ago by admin

​solar system Changed 1 year ago by admin

​stair parts Changed 1 year ago by admin

​solar supply Changed 1 year ago by admin