-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for IMAP labels #769
Comments
What needs to be done is:
The order would be used to sort multiple IMAP labels (1st sort), fallback is to order the labels on meaningful text (2nd sort) and fallback for that is to sort them on their original value (3rd sort). These labels can be more useful than the well known stars, especially when using https://en.wikipedia.org/wiki/Getting_Things_Done The displaying of labels would use up header space of the message view, but it is up to the user to keep meaningful labels short and to add colors. In that way, only one line in the header would be needed. Displaying in folders could be done by color only, only challenge is what to do when multiple colors are added. Thunderbird gives priority to the most important label. For this order can be used. So if a message has labels "C" and "F" which are respectively mapped to "To Do", order=0, color=#EE88EE and to "Waiting", order=1, color=#FF8800, then on message view both label will be shown, first To Do in purple and then Waiting in orange. In folder view, the message will have purple text color in the subject. Optionally, instead of giving the subject of a message in folder view a different color, the user might want the background color of that message in folder view to have a color. That would be similar as how it is offered in Thunderbird. Perhaps the user can choose either way. See also #558 and https://code.google.com/p/k9mail/issues/detail?id=2532 and https://code.google.com/p/k9mail/issues/detail?id=4101 |
JFYI,
#558 does that (in the ugliest way possible).
Not there yet, but close. I lack the Android UI skills to make this usable, but the backend code is pretty much there already.
will still take some work after #558. |
Looking forward to the result. You can ask for help at the UI guys |
Added bounty for this one, see https://www.bountysource.com/issues/26376747-add-support-for-imap-labels Hope this helps. |
I actually collected these for another issue, but I thought maybe the links are useful in one place:
And in one of these I found two bountys: |
I believe this feature needs some design work before it is ready to be implemented. Here's my list of unordered thoughts on this:
|
conflicts with
and the fact that clients like Thunderbird already support this.
In reality while I mentioned WebDAV briefly, WebDAV doesn't document any way of storing tags. And POP3 obviously doesn't. So synced tags really are IMAP only. Local tags obviously could be stored on any message. I don't think that's a particular problem - you just don't update custom tags if the account doesn't support fetching/setting custom tags.
We don't have much space. A small chit maybe, next to the attachment chit on the redesign. But I don't think we should spend too much time on how it looks pre-redesign, only that it's considered in the re-design. Changing the background/text also prohibits multiple tags. MLF is indeed ugly. It's a view and a controller that enforces behaviour on the data model. I'm more than a bit grumpy if we really think killing the PR is a good idea though. |
I don't get that. From the user's perspective e.g. marking a message as read and adding a tag are totally unrelated operations in Thunderbird, too. All I wanted to say was that I don't want tags to be saved as flags in our database just because that's how it works with IMAP. It's an implementation detail that we don't have to copy in our internal data model. But of course we will map "K-9 Mail tags" to IMAP flags/keywords.
I don't see all the changes I consider necessary for this to be implemented cleanly happening anytime soon. What's the alternative to closing the PR? Merging the code and hoping that someone will clean it up later hasn't worked once in the past. |
I do agree that tags should be separate from other flags in our data model. I don't quite see why this can't work in a minimum viable way and sync with imap though? At some point we have to work with the resources we actually have, or we set ourselves up for stagnation. It's possible that this is not one of these cases where we a reasonable intermediate feature is achievable, but we should at least make an effort to find out, especially if someone is actually doing the work. |
I am also in favor of simple independent implementation for IMAP only. First, start to show them, editting, managing names and colors, searching, ordering can be done later. |
PR #2668 started as a working prototype. So far it at least helped to spot several design issues that need clarification. In addition, I already learned a lot working on it. :-) Personally I don't mind whether the PR is kept alive as work in progress or gets dropped and (some day) succeeded by one or more new PRs. In any case, I am happy to contribute to the design work and the implementation, if there is a chance to make progress. I can spend some hours or a day every now and then. Regarding cleaning up later, my experience is that it usually never happens. Therefore the fundamental design should be sound before some PR gets merged. At the same time I think we can put some features on the wish list for later. What is the preferred way to go forward? Continue the discussion here and sketch a high-level overall plan? Raise other, more specific issues or PRs? I can imagine a granularity on the level of "design data model for tags", which might result in some page in the development section on k9mail.github.io, and later "extend local store for tags", then work on IMAP, UI, and so on. Here are my thoughts on some of the specific issues raised above:
I agree, we should keep that separate. Since this touches the very base of PR #2668 and its predecessors (8eea618), I also think that starting from scratch makes sense.
For me one global set of tags would be fine, But I agree that there are use-cases where account-specific tags make sense. And I think, there are also use-cases where one set of tags should be used for more than one account. So, there is a third option - sadly, it is more complex: Have one or more sets of tags on the global level and link each account to one of these sets. Changing one of the simpler implementations later into this wouldn't be fun. So, we might better live with the higher complexity from the start. Or is it over the top?
Changing the background color was inspired by Thunderbird. It is exactly what I need, but I did not expect all people to like it. It should be optional, and there should be other options. In the PR I already considered to optionally add a set of colored tag icons left of the star icon in the message list and message view. The star icon could be made optional also in the message view. And the tag icons could be limited to just one - at the users choice. Just some ideas for a start...
Multiple tags can still be assigned to a mail, but this way we can show only one of them in the list. The PR picks the color of the first assigned tag according to the user-defined order, again inspired by Thunderbird. The full list can be seen in the message view. |
It should be possible to both refactor the tables and keep it as a single query. I'll open a ticket for reviewing/reworking how we organise data in the database. |
Are there further opinions regarding the question whether there should be
I would like to sketch a data model just for the basic sets (or set) of tags, for example on a new page in the development section of the website. This could then serve as a basis for further discussion. And, of course, please stop me at any time, if you think, I am on the wrong track! |
I imagine the best way would be to have a list of tags per account, possible retrieved from the IMAP server if it implements the functionnality (https://tools.ietf.org/html/rfc3501#section-2.3.2), and if it doesn't, to propose the classical list of five tags in Thunderbird. |
Just tossing my use case in here for reference. If anyone else has different use cases, it's perhaps also a good idea to comment on that here. If you have the same use-case, i'd suggest just using the reaction-smileys on the specific post. (also: if you think this is a stupid idea, stop me, too ;-) ) So, here it goes: I am using K-9 with three different accounts. I access those accounts only from K-9 and Thunderbird (with the exception of some webmailer every now and then, but I digress). To me, having a centralised set of labels would be enough. I do not require @Trogel's option 2 or option 3 (I am not at all against those, I'd just not need them). |
I use the same way as @ccoenen |
Thanks for your feedback! Since there is demand for both options 1 and 2, I'd go with option 3 that provides most flexibility. PR k9mail/k9mail.github.io#57 starts off a design document for message tags as a basis for further discussion. Looking forward to your feedback in the PR! |
Any news on IMAP labels implementation? |
I am sorry, but I simply ran out of time. Unfortunately I cannot say when the situation will change. #2668 won't be merged (which is fine for me) and k9mail/k9mail.github.io#57 now looks somewhat over the top to me. Therefore and also since I cannot work on them in the foreseeable future, I will close both pull requests. Thanks for your great work on k9! It is still my favourite mail client on Android. Just the IMAP keywords are missing... ;-) @wokawoka: There are a few screenshots in #2668, but there are no experimental versions of k9 with that feature available, as far as I know. |
I too have the exact same use-case as @ccoenen and would very much appreciate this feature being added. And personally I would be totally fine with an absolutely minimal approach, like having K9 just show already existing labels set with another client (e.g. Thunderbird). |
I, too, would love to have this functionality. My use is pretty similar to #769 (comment) Also, for handling colors (ie, coloring the background of a message summary in list view) when there are multiple tags: I recommend doing what Thunderbird does and have the highest order tag's color be the one that is used for the background color. I've setup my tags with an understanding of that behavior and it's worked fine for me. And then of course within the message itself display each tag with it's corresponding color. The screenshots from the earlier attempt at all this look right to me: #2668 (comment) |
This comment has been minimized.
This comment has been minimized.
This comment was marked as off-topic.
This comment was marked as off-topic.
I and My colleague (@mhf1998) designed a demo for message list which may help you to have vision about its design: |
Can the localization be supported so it works out of the box? The files needed for this are available in Thunderbird's repo. |
What's the current status of this? I currently sort my Zoho mail using tags so it's a bit painful that all emails to all domains are sitting in one mailbox |
I could only find these tests:
Where can I find the source files that define the default tags, and possibly where they are translated? |
Ah, that was a bit of a search. Here are the tag definitions to (preferably) support by default as they are used too by Thunderbird: https://github.com/mozilla/releases-comm-central/blob/master/mail/locales/en-US/chrome/messenger/messenger.properties#L207 Because the Thunderbird in use can be in another language, the translations of tags can be found in these downloads:
The locals that are available are: https://github.com/mozilla/releases-comm-central/blob/master/mail/locales/shipped-locales these need to be cross checked with the locales supported by K-9 which are in https://github.com/thundernest/k-9/tree/main/app/ui/legacy/src/main/res ( If the developer working on supporting IMAP labels finds it useful, I can make a Python script that does all of the above and generate localized names for default Thunderbird IMAP tags. Perhaps that must be a setting in K-9 to use this mapping or not. |
@CoachDom does Zoho mail have any default tags it supports? https://www.zoho.com/mail/help/applying-tags.html?zredirect=f&zsrc=langdropdown&lb=de |
Here is a script that collects all tag translations https://pastebin.com/vjPyiMjJ (at the moment, it will only write to the command line) |
Hello, would it make sense to implement it as an plugin / addon? |
For me, this should be standard functionality. |
So is there a Roadmap available? I think Mozilla is a big institution which plans the development. But where is the plan and who can be assigned to this open issue? |
I propose to discard previous ideas and discussions and just copy Thunderbird desktop functionality to Thunderbird android. For anyone using tags it is a major handicap of Thunderbird android not supporting labels. |
Plesse add support for IMAP Labels/flags/tags, just like Mozilla Thunderbird does. Thank you.
The text was updated successfully, but these errors were encountered: