Closed Bug 1595824 Opened 6 years ago Closed 4 years ago

better support for gloda/message search

Categories

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

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: buecher, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

  1. messages.json does not allow to query for tags.
    needed is something like
    "tags": {
    "type": ??, ??required nsIMsgTags for gloda query??
    "optional": true,
    "description": "Returns only messages with the given tags."

           },
    

and in ext-messages.js in async query(queryInfo) something like

if (queryInfo.tags) {
        query.tags(queryInfo.tags);
      }
  1. Gloda queries are limited to 300 (??) return values. I remember that can be set somewhere but don't remember where. Does that work with webextensions?
Blocks: webext-tb

it seems that doesn't go well with MessageTag in webapi - that would need to be converted to an nsIMsgTags?

The first issue is being handled in bug 1600547.

For the second, the limit is set by mailnews.database.global.search.msg.limit and appears to be 1000 by default. That will also apply to WebExtensions.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE

Thanks for adding that functionality.

a) mailnews.database.global.search.msg.limit: it should be possible to set that from an addon. (when doing backup of something with many returned messages.)

b) At minimum, one needs to be able to read the pref, then one could test whether number returned === pref and notify the user. Better if combined with a), because it is not clear whether end user is capable to change the pref (my wife might need the backup but would not be able to set the pref)

Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

We no longer use gloda for message search in the WebExt API, so the preference mailnews.database.global.search.msg.limit is no longer relevant.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago → 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.