Closed Bug 1898585 Opened 1 year ago Closed 6 months ago

No equivalent of MailServices.tags.addTag(name, color, ordinal) in Extensions API: messages createTag requires user to come up with key

Categories

(Thunderbird :: Add-Ons: Extensions API, defect)

Thunderbird 115
defect

Tracking

(Not tracked)

RESOLVED FIXED
136 Branch

People

(Reporter: jhh, Assigned: TbSync)

Details

Attachments

(1 file)

Steps to reproduce:

There is no reliable way to create a new tag using the Extensions API such that the key used for a new tag would correspond to the key generated for the same tag through Thunderbirds UI (Message > Tag > New Tag...). The latter uses MailServices.tags.addTag(name, color, ordinal), but this function is not exposed in the Extensions Messages API. Closest is messenger.messages.createTag(key,tag,color), but this requires the caller to make up a key for the new tag.

Expected results:

An equivalent of MailServices.tags.addTag in the Extensions Messages API (preferably one that returns the generated key ;-).

In this case this is (somewhat) of a problem, because an extension cannot create tags (with messenger.messages.createTag()) using the same key encoding as "Manage tags..." would do when the same complex tag containing non ASCII characters is added. This creates compatibility issues when importing Xbox files with tag information stored in X-Mozilla-Keys created using messenger.messages.createTag() in a new profile where tags are added using "Manage tags...".

Can you give an example, of what you try to achieve? What are your exact inputs and what do you want to have as output? Where does the current API fail for you?

If I create a tag using the Thunderbird UI using Message > Tags > New Tag.. this creates the tag (using MailServices.tags.addTag) with key a&aom-. Suppose such a tag is created in a version of Thunderbird on another machine, and I import the (tagged) messages in a new install on a new machine. Now if an extension wants to create the same tag , there is no reliable way for it to create this tag with the same key used in the imported messages. Meaning the imported messages will not be recognised as being tagged by this tag.

Because the API does not allow to use a&aom- as key? Can you check if that has been changed for Beta? I do remember something in that area....

Indeed, Beta now allows a&aom- and even as key, which is an improvement.

The problem is however that if I create a tag through Message > Tags > New Tag... the key a&aom- is automatically generated when I enter the tag . If I want to manage tag through an extension, I am limited to the extension API. If my extension should be backwards compatible with tags created using the Thunderbird UI, then I somehow need to compute this exact same key and give it to messenger.messages.createTag which is non trivial. While there is a function within Thunderbird that does exactly that (namely MailServices.tags.addTag), but to which I have no access.

Coming back to this. Would it be sufficient to make the key parameter of messenger.messages.createTag() optional? In that case the function could return the auto-generated key.

To be bulletproof, we would need to actually remove the option to freely define the key for a tag, because otherwise you would still not be able to re-create tags on system B, if they have been created by add-ons on system A. When importing messages from system A into system B, you probably need to also import the key-name mapping of tags from system A.

Note: IIRC, Thunderbird no longer stores tags in the actual message. We did it for IMAP a few years ago, but we no longer do. Are you working with old exported data which still has the keys in the messages?

That would indeed work provided the function actually does return the key (the same one that would have been generated when MailServices.tags.addTag would have been called).

Yes, Thunderbird no longer stores tags in the actual messages in an Inbox. It still does store them in the archived messages (but only if the archive is compacted).

Currently, messages.tags.create() requires specifying a tag name and a
tag key. While this provides maximum flexibility, there are also
scenarios where the add-on has no need to come up with a specific key or
actually wants to use the exact same key that would be used if the tag
is created through the UI.

This patch makes the key parameter optional and returns the key
associated with the created tag.

Assignee: nobody → john
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → 136 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/580fb9c33d7a
Auto-generate tag key if not provided. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: