add status to "star" e-mails to Tracker Mail add-on

[grexe]

I need an easy and quick way to star or flag a mail so to mark it as important. This is now considered a core feature when working with mail and is commonly used. I don't want to move it to another folder but keep the original file organisation.

I found no way to configure the E-Mail Tracker add-on to add this status and think this important functionality should be exposed through the mail settings and possible the E-Mail app itself, too.

[humdinger]

It's done from the Mail app, see ​file:///boot/system/documentation/userguide/en/workshop-email.html#status

Once you've added your custom status - like "level 1", "urgent", or "whenever" - you can set it also via the Tracker add-on.

[grexe]

Somehow that completely escaped my attention, sorry for that.

Could we at least add a menu item "configure..." in the Tracker add-on to close the circle and bring up these settings? It's done in a similar way for email queries and also in other places, so this would improve consistency.

[humdinger]

Agreed, maybe an item "New status…" as last item of the menu that pops up when you use the Tracker Add-on "Mark as…". The rest'll work as it's done in the Mail app.

(Though, IMO it would be good to make managing statuses nicer in general by having a regular window listing all statuses and Add/Remove buttons.)

Since with our discoveries neither this ticket's title nor contents really fits any more, wanna open a new one?

[grexe]

sadly I cannot change the title, only the content. Will open a new issue.

However, the original RFE is still worth considering imo, as this is something different. A flag is just a boolean to quickly label the mail as open/action item/whatever. It has simpler semantics than a real status.

I think we need *both*, because the mail status has richer semantics that can be *combined* with a flag, like Starred AND status:"Waiting for reply" or similar.

Adding a boolean to the MAIL file type would be really easy to do and this is much more prominent and straightforward than having to use a Tracker add-on just to handle the mail status...

Many e-mail clients have kind of both, combining the two into a colored flag. GMail uses *only* a star to flag mails. The status is fixed to read/archived and the rest is handled via labels/virtual folders there.

[grexe]

Heck this was so easy, don't we love Haiku and its native file types? :) I created a MAIL:starred boolean with a "Special" setting of 2 star icons (solid, outline) and it looks like it was always designed that way:)

It's not directly visible in the screenshot, but you can see that it makes sense to have starred/unstarred e-mail regardless of the status.

Shouldn't this be the default?

PS: if still not convinced, consider the Eisenhower matrix. Mail messages may be important but not urgend and any combination of these two.

[grexe]

extended E-Mail filetype with Star boolean flag

[grexe]

done, see #19332

Replying to humdinger:

Agreed, maybe an item "New status…" as last item of the menu that pops up when you use the Tracker Add-on "Mark as…". The rest'll work as it's done in the Mail app.

(Though, IMO it would be good to make managing statuses nicer in general by having a regular window listing all statuses and Add/Remove buttons.)

Since with our discoveries neither this ticket's title nor contents really fits any more, wanna open a new one?

[grexe]

PS: just can't for the life of me get a Terminal query to work (Find panel still crashing here, need to investigate). Is this a bug or what am I doing wrong? I did a reindex, copied the mail to a new file so to force all attributes to be rewritten and reindexed, no success:

~> listattr -l  /boot/home/mail/SEN\ Labs/in/Inbox/some-mail 
File: /boot/home/mail/SEN Labs/in/Inbox/some-mail
        Type       Size  Name                                Contents
-------------------------------------------------------------------------------
     Uint-32         4  "IMAP:uidvalidity"                  1
        Text         5  "MAIL:unique_id"                    3248
     Uint-32         4  "IMAP:flags"                        1
      Int-32         4  "MAIL:account_id"                   1718382032
        Text         9  "MAIL:account"                      SEN Labs
        Text        30  "MAIL:to"                           semantic.ex...
        Text        62  "MAIL:from"                         "Alexander..."
      'TIME'         8  "MAIL:when"                         Wed Jan  1 17:49:03 2025
        Text        28  "MAIL:reply"                        hello@...
        Text        24  "MAIL:subject"                      The venerable hyperlink
        Text         4  "MAIL:mime"                         1.0
        Text        32  "MAIL:name"                         Alex...
        Text        24  "MAIL:thread"                       The venerable hyperlink
        Text         5  "MAIL:status"                       Read
 MIME String        13  "BEOS:TYPE"                         text/x-email
      Int-32         4  "MAIL:header_length"                6183
      Int-32         4  "MAIL:read"                         2
       Float         4  "MAIL:read_pos"                     0.000000
     Boolean         1  "MAIL:starred"                      1

269 bytes total in attributes.

~> cp -a /boot/home/mail/SEN\ Labs/in/Inbox/some-mail test.mail
~> query -fa MAIL:starred==1
~> query -fa MAIL:starred=1
~> query -fa "MAIL:starred==1"
~> query -fa "MAIL:starred=1"

[humdinger]

Agreed on the addition of "MAIL:starred". I guess, I personally haven't missed it...

You wrote that you "reindex"ed. Did you also add the new attribute to the index in the first place with "mkindex MAIL:starred"? Does "lsindex" show it?

[humdinger]

FWIW, I haven't been able to query for it either...

Is it possible that there's an issue with the attribute being boolean, but there's no type=boolean when creating an index? I used a normal "int", assuming that'd deal with the 0 or 1 values.

[grexe]

Yeah that's what I also thought - although mkindex should know what type to use since it's already clear from the file type definition and I don't want to repeat myself..

[humdinger]

Leaving aside the reasons why it doesn't work with boolean attrbutes, it does work when creating the attribute as integer (I checked with int32, if that matters). One might have assumed that the "checkbox" only worked for "boolean", but one would be mistaken... :)

[grexe]

I never noticed this issue - so it's really a bug in BQuery? In that case I would create a separate issue if this is true.

[humdinger]

Not sure it's a bug or some side effect of the implementation somewhere... But it'd be an enhancement one would expect to be able to query for bools as well.

[grexe]

OK I did some research and testing and there are several factors at play. This was also raised back in the day with #4636 but marked as invalid - I think the issue might have been similar infact.

1. there is no index type bool, so if you create a Boolean attribute in FileTypes, you won't be able to search for it [1]
2. mkindex -t int actually creates an index for an int32 value and will only work with that. I tried creating an int8 attribute with FileTypes to save space (even that is a waste for a boolean...) and it would not work.
3. if you need to reindex, the changes might not be found (at least with the '-r` option to scan a whole directory. Seems I hit a caching problem with my SSD, 2nd time a bit later or providing the file explicitly it worked.

So for a "Boolean" flag you need to:

1. create an int32 attribute
2. index with -t int
3. reindex if needed - mind the cache!

Regarding this issue, that means imo:

1. fix FileTypes to avoid this confusion - it needs a "Searchable" option similar to the "Editable" option, too, else we are giving away the coolest feature of Haiku(FS) and confuse users without any need, but that's another issue.
2. possibly introduce a boolean index - is this supported by BFS or would this require filesystem changes?

[1] mkindex -t option must be one of "int", "llong", "string", "float", or "double" and defaults to "string". This is what I accidentally did for my starred attribute.

[humdinger]

As I said before, I normally don't "star" emails. I've now "starred" a mail on my phone, and lo! The email arrives with the status "Starred".

Now I agree even more that the "Starred" should be an attribute separate from the the ususal "Status": May usual query for MAIL:status=="New" didn't catch the new 'starred' email... :)