Enhancement: support for user tagging about cypht HOT 15 OPEN

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!

from cypht.

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.

from cypht.

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

from cypht.

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?

from cypht.

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).

from cypht.

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.

from cypht.

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.

from cypht.

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.

from cypht.

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! :)

from cypht.

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 :(

from cypht.

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

from cypht.

Related feature request: roundcube/roundcubemail#4986

from cypht.

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

from cypht.

"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.

from cypht.

Assigned colors to tags. We can use/extend: #450

from cypht.