[GH-ISSUE #13] Enhancement: support for user tagging (tags / labels) #11

New issue

Closed

opened 2026-02-25 21:33:54 +03:00 by kerem · 20 comments

kerem commented 2026-02-25 21:33:54 +03:00

Owner

Copy link

Originally created by @dumblob on GitHub (Aug 4, 2015).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/13

Originally assigned to: @Shadow243 on GitHub.

Some very basic tagging/labeling (so that it doesn't bloat the user interface) with filtering based on these tags/labels would be nice to have.

The implementation would use just IMAP flags/keywords (see an older short article with useful hints: http://deflexion.com/2006/05/server-side-message-labels). And of course, I wouldn't pay attention to Mozilla-based clients etc. and just left the default tag set blank without any presets. I.e. solely up to the user what the tags will be (if the user wanted old-thunderbird-compatible tags, then he can just write them as $My_awesome_tag4 to exchange the fourth Mozilla tag with this one).

Originally created by @dumblob on GitHub (Aug 4, 2015). Original GitHub issue: https://github.com/cypht-org/cypht/issues/13 Originally assigned to: @Shadow243 on GitHub. Some very basic tagging/labeling (so that it doesn't bloat the user interface) with filtering based on these tags/labels would be nice to have. The implementation would use just IMAP flags/keywords (see an older short article with useful hints: http://deflexion.com/2006/05/server-side-message-labels). And of course, I wouldn't pay attention to Mozilla-based clients etc. and just left the default tag set blank without any presets. I.e. solely up to the user what the tags will be (if the user wanted old-thunderbird-compatible tags, then he can just write them as `$My_awesome_tag4` to exchange the fourth Mozilla tag with this one).

kerem 2026-02-25 21:33:54 +03:00

• closed this issue
• added the
  enhancement
  new module set
  tags
  labels

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@jasonmunro commented on GitHub (Aug 11, 2015):

Having used Cypht since before it was really usable - I'm needing this feature soon. This is a good sign that it will actually get done ;). "flagged" works in the interim, but tags/labels and the ability to "promote" one to the main folder list section would be really cool. Using IMAP flags/keywords is definitely the way to go (maybe with some Gmail optimizations if we can leverage them). We will have to come up with work-arounds for other data sources (POP3, feeds, etc), but it's the same with read/unread status, so no biggie :). BTW, I really appreciate all your thoughtful feedback!

<!-- gh-comment-id:129703182 --> @jasonmunro commented on GitHub (Aug 11, 2015): Having used Cypht since before it was really usable - I'm needing this feature soon. This is a good sign that it will actually get done ;). "flagged" works in the interim, but tags/labels and the ability to "promote" one to the main folder list section would be really cool. Using IMAP flags/keywords is definitely the way to go (maybe with some Gmail optimizations if we can leverage them). We will have to come up with work-arounds for other data sources (POP3, feeds, etc), but it's the same with read/unread status, so no biggie :). BTW, I really appreciate all your thoughtful feedback!

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@jasonmunro commented on GitHub (Dec 30, 2015):

Been looking into this today. I want to use IMAP custom keywords so we can store the labels like flags on the IMAP server itself. Not all services support this however, so we will have to work around those that don't (outlook365 does not, surprise!). Looks like Gmail and many of the more popular Open Source servers do support it (dovecot, cyrus, uw, courrier) but it's hit or miss. We could fall back to storing label information locally for services that don't support it (and for content that is not from IMAP) but I think to start I will build it around the IMAP custom flag ability and see how it goes.

<!-- gh-comment-id:168096249 --> @jasonmunro commented on GitHub (Dec 30, 2015): Been looking into this today. I want to use IMAP custom keywords so we can store the labels like flags on the IMAP server itself. Not all services support this however, so we will have to work around those that don't (outlook365 does not, surprise!). Looks like Gmail and many of the more popular Open Source servers do support it (dovecot, cyrus, uw, courrier) but it's hit or miss. We could fall back to storing label information locally for services that don't support it (and for content that is not from IMAP) but I think to start I will build it around the IMAP custom flag ability and see how it goes.

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@dumblob commented on GitHub (Dec 31, 2015):

Great news! I'll take a look at the progress asap.

<!-- gh-comment-id:168153085 --> @dumblob commented on GitHub (Dec 31, 2015): Great news! I'll take a look at the progress asap.

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@jasonmunro commented on GitHub (Dec 31, 2015):

nothing to see yet, except for basic support in the IMAP lib for setting custom keyword flags. Any thoughts on how you would incorporate this into the UI?

<!-- gh-comment-id:168228205 --> @jasonmunro commented on GitHub (Dec 31, 2015): nothing to see yet, except for basic support in the IMAP lib for setting custom keyword flags. Any thoughts on how you would incorporate this into the UI?

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@dumblob commented on GitHub (Jan 2, 2016):

Well, that's a tough question ;) I don't have any strong opinions on this, but I see two main use-cases:

1. adding, removing, and editing tags to/from emails and also the tags themself

   Here I'd like to see as many existing tags as possible and have the opportunity to add tag to email both without typing and with typing (yes, I count both with desktops and tablets) and then easy removal and adding of tags themself. That said, I think a hiding vertical panel (e.g. on the right side of an email edit form) having a full height and containing an alphabetically sorted list of all tags with a tag search field at the top and possible tabs (and possibly buttons doing something meaningful - import/export tags, undo/redo during "transaction" as described at the bottom, etc.) upon this search field for other possible additional tools or features or whatsoever in the future might be an option.

   Clicking a tag in the list would make it non-clickable and add the tag to the email (I've been considering dragging, but that takes more time and would be more bloated in implementation). I don't know though how to show tags in the email itself - maybe in a field under the email title? Or just in another tab of this hiding panel? Or yet something different? Representation of the tags added to an email must also support removal (in the name of consistency it should look the same as in the list, even though it will just remove the tag from the email, but not from the list of all available tags).

   Each item (a tag) in the list will have a close sign to remove the tag from the list, effectively discarding the tag from everywhere (should we check all emails tagged with this tag and in case there are some warn user before proceeding). We might also add an edit sign to edit existing tags (I don't know if this is supported by IMAP, because if not, we would need to add a new tag, find all emails with the edited tag, add the new tag and remove this old tag - this would be quite inefficient but sometimes very handy).

   Speaking about tagged emails, I've found out that some tag UI implementations show number of objects tagged with the particular tag right next to the tag name - though, I've no idea what this information might be good for (because it's easily obtainable as a number of found emails when searching emails and filtering them based on the particular tag).

   For adding new tags to the tag list, under this list, there will be an empty text input field and an "add" button next to it allowing new tags to be added.

   See also below some hints about general disadvantages.

2. filtering/search based on tags

   This might be again the same panel as above, but a click on a tag will add the tag to the search field(s).

There are though two issues I'm concerned about.

First, accidental removal of a tag - I don't like dialog windows and such, so I've been thinking about some "undo" feature implemented only in the UI layer, so that the changes in tagging would not take any effect (i.e. not send any IMAP messages) until the user didn't close the email or somehow "finished" the logical operation. This way, it would have sort of a transactional feeling and should be easy to implement, providing good prevention of mistakes and be enough "real-time" (the changes wouldn't be visible in other sessions until the opened email was closed).

Second, I sometimes lack the possibility to tag emails directly from a list of emails (e.g. a list resulting from a search). If we allowed opening the "tags panel" not only for an opened email, but also for a list of emails, we would need to think about delimitation of the "transaction" (as described above). Maybe all major (from the user's perception of the UI) changes should delimit the "transaction" (beginnings and ends).

<!-- gh-comment-id:168386876 --> @dumblob commented on GitHub (Jan 2, 2016): Well, that's a tough question ;) I don't have any strong opinions on this, but I see two main use-cases: 1. adding, removing, and editing tags to/from emails and also the tags themself Here I'd like to see as many existing tags as possible and have the opportunity to add tag to email both without typing and with typing (yes, I count both with desktops and tablets) and then easy removal and adding of tags themself. That said, I think a hiding vertical panel (e.g. on the right side of an email edit form) having a full height and containing an alphabetically sorted list of all tags with a tag search field at the top and possible tabs (and possibly buttons doing something meaningful - import/export tags, undo/redo during "transaction" as described at the bottom, etc.) upon this search field for other possible additional tools or features or whatsoever in the future might be an option. Clicking a tag in the list would make it non-clickable and add the tag to the email (I've been considering dragging, but that takes more time and would be more bloated in implementation). I don't know though how to show tags in the email itself - maybe in a field under the email title? Or just in another tab of this hiding panel? Or yet something different? Representation of the tags added to an email must also support removal (in the name of consistency it should look the same as in the list, even though it will just remove the tag from the email, but not from the list of all available tags). Each item (a tag) in the list will have a close sign to remove the tag from the list, effectively discarding the tag from everywhere (should we check all emails tagged with this tag and in case there are some warn user before proceeding). We might also add an edit sign to edit existing tags (I don't know if this is supported by IMAP, because if not, we would need to add a new tag, find all emails with the edited tag, add the new tag and remove this old tag - this would be quite inefficient but sometimes very handy). Speaking about tagged emails, I've found out that some tag UI implementations show number of objects tagged with the particular tag right next to the tag name - though, I've no idea what this information might be good for (because it's easily obtainable as a number of found emails when searching emails and filtering them based on the particular tag). For adding new tags to the tag list, under this list, there will be an empty text input field and an "add" button next to it allowing new tags to be added. See also below some hints about general disadvantages. 2. filtering/search based on tags This might be again the same panel as above, but a click on a tag will add the tag to the search field(s). There are though two issues I'm concerned about. First, accidental removal of a tag - I don't like dialog windows and such, so I've been thinking about some "undo" feature implemented only in the UI layer, so that the changes in tagging would not take any effect (i.e. not send any IMAP messages) until the user didn't close the email or somehow "finished" the logical operation. This way, it would have sort of a transactional feeling and should be easy to implement, providing good prevention of mistakes and be enough "real-time" (the changes wouldn't be visible in other sessions until the opened email was closed). Second, I sometimes lack the possibility to tag emails directly from a list of emails (e.g. a list resulting from a search). If we allowed opening the "tags panel" not only for an opened email, but also for a list of emails, we would need to think about delimitation of the "transaction" (as described above). Maybe all major (from the user's perception of the UI) changes should delimit the "transaction" (beginnings and ends).

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@jasonmunro commented on GitHub (Jan 4, 2016):

Thanks for all the great ideas! Some random thoughts I had while reading this:

1. We will need to store the tag list locally in the user settings. This means having to use the "save" page or "save on logout". Not a huge deal (and really, saving anything locally is designed to require user consent, not to mention required by the encryption routines). This sort of parallels the "transaction" concept. We could cache the messages to tag in the session, and only update the flags remotely in the IMAP store when the local settings are saved.
2. Data sources. Currently, all the combined views (unread, flagged, search, everything) default to using only the IMAP account INBOX. If you browse to another folder in an Email account, there are controls to add it to the combined view in the upper right. You can view what sources are included in a combined view in the same location (the little folder icon). I bring this up to clarify that only folders selected for combined views will be included when listing/searching by tag.
3. Non-IMAP tagging. I want to support this sooner than later - And I think the way to go here is to build a simple key/value DB storage mechanism that we can use to store tagged content. Things drop off the end of RSS feeds pretty quickly, so associating a tag with the UID is not very useful if we can't retrieve content for the UID from the source. I'm thinking username, tag, content UID, list_path, and an encrypted blob for the content itself will do the trick.

<!-- gh-comment-id:168727616 --> @jasonmunro commented on GitHub (Jan 4, 2016): Thanks for all the great ideas! Some random thoughts I had while reading this: 1. We will need to store the tag list locally in the user settings. This means having to use the "save" page or "save on logout". Not a huge deal (and really, saving anything locally is designed to require user consent, not to mention required by the encryption routines). This sort of parallels the "transaction" concept. We could cache the messages to tag in the session, and only update the flags remotely in the IMAP store when the local settings are saved. 2. Data sources. Currently, all the combined views (unread, flagged, search, everything) default to using only the IMAP account INBOX. If you browse to another folder in an Email account, there are controls to add it to the combined view in the upper right. You can view what sources are included in a combined view in the same location (the little folder icon). I bring this up to clarify that only folders selected for combined views will be included when listing/searching by tag. 3. Non-IMAP tagging. I want to support this sooner than later - And I think the way to go here is to build a simple key/value DB storage mechanism that we can use to store tagged content. Things drop off the end of RSS feeds pretty quickly, so associating a tag with the UID is not very useful if we can't retrieve content for the UID from the source. I'm thinking username, tag, content UID, list_path, and an encrypted blob for the content itself will do the trick.

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@dumblob commented on GitHub (Jan 4, 2016):

Ad 1) I'm glad, that the "transaction" mechanism wasn't completely unrelated. The proposed caching is IMHO a good way to go.

Ad 2) Good to know, thanks! Maybe some title attribute might warn user about this fact to prevent surprise and disappointment.

Ad 3) You're right with the missing IDs. But I'm not proficient in making such storage engines (not counting the HTML 5 storage nor cookies), so can't comment much on this. The combination username, tag, content UID, list_path, and an encrypted blob sounds fine though on the first glance.

<!-- gh-comment-id:168818541 --> @dumblob commented on GitHub (Jan 4, 2016): Ad 1) I'm glad, that the "transaction" mechanism wasn't completely unrelated. The proposed caching is IMHO a good way to go. Ad 2) Good to know, thanks! Maybe some _title_ attribute might warn user about this fact to prevent surprise and disappointment. Ad 3) You're right with the missing IDs. But I'm not proficient in making such storage engines (not counting the HTML 5 storage nor cookies), so can't comment much on this. The combination _username, tag, content UID, list_path, and an encrypted blob_ sounds fine though on the first glance.

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@jasonmunro commented on GitHub (Jan 5, 2016):

1. Interestingly, the requirement to re-enter your password to save something between logins is driven by the encryption design, but I also think that while it's quite different than the way most web apps work, it's really privacy driven and a good thing. If only I could convince users of that! :)
2. I'm thinking we need a "combined view source management" page where this can all be clearly spelled out and configured.
3. I would leverage the session for this where possible, but concurrent requests are not "thread safe" on the server (one request's session overwrites the other), so we need something more atomic.

<!-- gh-comment-id:168862589 --> @jasonmunro commented on GitHub (Jan 5, 2016): 1. Interestingly, the requirement to re-enter your password to save something between logins is driven by the encryption design, but I also think that while it's quite different than the way most web apps work, it's really privacy driven and a good thing. If only I could convince users of that! :) 2. I'm thinking we need a "combined view source management" page where this can all be clearly spelled out and configured. 3. I would leverage the session for this where possible, but concurrent requests are not "thread safe" on the server (one request's session overwrites the other), so we need something more atomic.

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@jasonmunro commented on GitHub (Mar 7, 2016):

This fell off the radar for a bit, but it's still high on my list. Darn real-life stuff is taking up all my time! :)

<!-- gh-comment-id:193374358 --> @jasonmunro commented on GitHub (Mar 7, 2016): This fell off the radar for a bit, but it's still high on my list. Darn real-life stuff is taking up all my time! :)

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@dumblob commented on GitHub (Mar 7, 2016):

Darn real-life stuff is taking up all my time! :)

No worries and no hurry - I'm also right now very busy and therefore I didn't even test some fixes made in Cypht during the last 2 months :(

<!-- gh-comment-id:193449695 --> @dumblob commented on GitHub (Mar 7, 2016): > Darn real-life stuff is taking up all my time! :) No worries and no hurry - I'm also right now very busy and therefore I didn't even test some fixes made in Cypht during the last 2 months :(

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Nov 12, 2019):

I will also use this quite a bit.
We should keep in mind the new possibilities of https://jmap.io/

<!-- gh-comment-id:552710292 --> @marclaporte commented on GitHub (Nov 12, 2019): I will also use this quite a bit. We should keep in mind the new possibilities of https://jmap.io/

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Jul 30, 2022):

Related feature request: https://github.com/roundcube/roundcubemail/issues/4986

<!-- gh-comment-id:1200315430 --> @marclaporte commented on GitHub (Jul 30, 2022): Related feature request: https://github.com/roundcube/roundcubemail/issues/4986

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Aug 12, 2022):

This is where it will be:
https://github.com/jasonmunro/cypht/tree/master/modules/tags

<!-- gh-comment-id:1212673761 --> @marclaporte commented on GitHub (Aug 12, 2022): This is where it will be: https://github.com/jasonmunro/cypht/tree/master/modules/tags

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Nov 8, 2023):

"Hint: Multi-User Mail Access
We use Thunderbird at Migadu for multi-user access of our support mailbox. We use Thunderbird tags to tag messages so we know who should or is already answering the message. We have only agreed ahead of time on the meaning of the colors.

This flow works surprisingly well as the server instantly syncs the tags between multiple Thunderbird instances. If you are a small team, you should try this out before you invest in a complicated ticketing system."

Source: https://www.migadu.com/guides/thunderbird/

I would like to be able to do this as well with Cypht.

<!-- gh-comment-id:1802884538 --> @marclaporte commented on GitHub (Nov 8, 2023): "Hint: Multi-User Mail Access We use Thunderbird at Migadu for multi-user access of our support mailbox. We use Thunderbird tags to tag messages so we know who should or is already answering the message. We have only agreed ahead of time on the meaning of the colors. This flow works surprisingly well as the server instantly syncs the tags between multiple Thunderbird instances. If you are a small team, you should try this out before you invest in a complicated ticketing system." Source: https://www.migadu.com/guides/thunderbird/ I would like to be able to do this as well with Cypht.

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Nov 8, 2023):

Assigned colors to tags. We can use/extend: https://github.com/cypht-org/cypht/issues/450

<!-- gh-comment-id:1802885800 --> @marclaporte commented on GitHub (Nov 8, 2023): Assigned colors to tags. We can use/extend: https://github.com/cypht-org/cypht/issues/450

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (May 21, 2024):

Also, we want this to work with Sieve filters: So filters can use labels as part of filtering, or an action can be to add / edit / remove labels.

<!-- gh-comment-id:2123551171 --> @marclaporte commented on GitHub (May 21, 2024): Also, we want this to work with Sieve filters: So filters can use labels as part of filtering, or an action can be to add / edit / remove labels.

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Jul 11, 2024):

@dumblob You asked for this 9 years ago, and here it is! :-)
https://github.com/cypht-org/cypht/pull/1058

This is the second oldest feature request that is still open!

<!-- gh-comment-id:2223577113 --> @marclaporte commented on GitHub (Jul 11, 2024): @dumblob You asked for this 9 years ago, and here it is! :-) https://github.com/cypht-org/cypht/pull/1058 This is the second oldest feature request that is still open!

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Aug 15, 2024):

Done!

<!-- gh-comment-id:2291143245 --> @marclaporte commented on GitHub (Aug 15, 2024): Done!

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@marclaporte commented on GitHub (Oct 21, 2024):

• https://www.cypht.org/modules.html reports "Tag content for easy searching/filtering. Not yet functional"
• https://github.com/cypht-org/cypht/tree/master/modules/tags reports "This module set is not yet functional. It is intended to provide users a way to organize content by tags/labels."

<!-- gh-comment-id:2425586088 --> @marclaporte commented on GitHub (Oct 21, 2024): - https://www.cypht.org/modules.html reports "Tag content for easy searching/filtering. Not yet functional" - https://github.com/cypht-org/cypht/tree/master/modules/tags reports "This module set is not yet functional. It is intended to provide users a way to organize content by tags/labels."

kerem commented 2026-02-25 21:33:55 +03:00

Author

Owner

Copy link

@Shadow243 commented on GitHub (Oct 21, 2024):

• https://github.com/cypht-org/cypht/tree/master/modules/tags

• https://github.com/cypht-org/cypht/pull/1293
• https://github.com/cypht-org/cypht-website/pull/81

<!-- gh-comment-id:2426375941 --> @Shadow243 commented on GitHub (Oct 21, 2024): > * https://github.com/cypht-org/cypht/tree/master/modules/tags - https://github.com/cypht-org/cypht/pull/1293 - https://github.com/cypht-org/cypht-website/pull/81

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

2.x

mta-sts-implementation

feat-compose-backspace-delete-recipients

release-2.5.1

add-tls3-support

1.4.x

enforce-coverage

release-2.4.2

strip_dns_prefetch_tags

fix_nightly_build

pr-title-validation-update

review-sent-email

revert-1339-fixed-tags-display

revert-1061-rem-cram-md5

sys-messages-revamp

revert-685-fixed-str-pos-warning-when-no-to

revert-590-empty-settings

release-1.3.0

revert-471-draft-add-warning

revert-454-feature/server-list-by-uniqid

php7.4-support

release-1.2.0

remove-mobile-media-queries

release-1.1.0

release-1.0.0

v2.7.0

v2.6.0

v2.5.1

v2.5.0

v1.4.7

v2.4.2

v2.4.1

v1.4.6

v1.4.5

v2.4.0

v2.3.0

v2.2.0

v1.4.4

v2.1.0

v2.0.1

v1.4.3

v2.0.0

v1.4.2

v1.4.1

v1.4.0

v1.3.0

v1.3.0-rc3

v1.3.0-rc2

v1.3.0-rc1

v1.1.0

v1.1.0-rc4

v1.1.0-rc3

v1.1.0-rc2

v1.1.0-rc1

v1.0.0

v1.0.0-rc8

v1.0.0-rc7

v1.0.0-rc6

v1.0.0-rc5

v1.0.0-rc4

v1.0.0-rc3

v1.0.0-rc2

v1.0.0-rc1

Labels

Clear labels   

2fa

  

I18N

  

PGP

  

Security

  

Security

  

account

  

advanced_search

  

advanced_search

  

announcement

  

api_login

  

authentication

  

awaiting feedback

  

blocker

  

bug

  

bug

  

bug

  

calendar

  

config

  

contacts

  

core

  

core

  

devops

  

docker

  

docs

  

duplicate

  

dynamic_login

  

enhancement

  

epic

  

feature

  

feeds

  

framework

  

github

  

github

  

gmail_contacts

  

good first issue

  

help wanted

  

history

  

history

  

imap

  

imap_folders

  

inline_message

  

installation

  

keyboard_shortcuts

  

keyboard_shortcuts

  

ldap_contacts

  

mobile

  

need-ssh-access

  

new module set

  

nux

  

pop3

  

profiles

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

refactor

  

release

  

research

  

saved_searches

  

smtp

  

strategic

  

tags

  

tests

  

themes

  

website

  

wordpress

No labels

2fa

I18N

PGP

Security

Security

account

advanced_search

advanced_search

announcement

api_login

authentication

awaiting feedback

blocker

bug

bug

bug

calendar

config

contacts

core

core

devops

docker

docs

duplicate

dynamic_login

enhancement

epic

feature

feeds

framework

github

github

gmail_contacts

good first issue

help wanted

history

history

imap

imap_folders

inline_message

installation

keyboard_shortcuts

keyboard_shortcuts

ldap_contacts

mobile

need-ssh-access

new module set

nux

pop3

profiles

pull-request

question

refactor

release

research

saved_searches

smtp

strategic

tags

tests

themes

website

wordpress

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/cypht#11

No description provided.