Skip to content
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 ability to mark messages as unread #685

Closed
uniquePWD opened this issue Feb 25, 2014 · 25 comments
Closed

Add ability to mark messages as unread #685

uniquePWD opened this issue Feb 25, 2014 · 25 comments
Labels

Comments

@uniquePWD
Copy link

That's something that's available in the AOSP Text Messaging app but is missing from TSM for Android.

@lImbus
Copy link

lImbus commented Apr 23, 2014

Is there a possibility to "sponsor" this issue ?

lImbus added a commit to lImbus/TextSecure that referenced this issue Apr 24, 2014
@mcginty
Copy link
Contributor

mcginty commented May 9, 2014

@lImbus you're welcome to submit pull requests if that's what you mean :)

@lImbus
Copy link

lImbus commented May 9, 2014

as a matter of fact, I have already started implementing it (forked and pushed, branch MarkUnread-Issue685). I do not know much about Android, but it compiles :)
Right now, I am struggling to test it. My second mobile phone card/number seems blocked for the registration process, and then my time was up and more important things took over. Maybe I should try to give it another hour this weekend.

@mejo-
Copy link

mejo- commented Sep 12, 2014

Would be awesome to have this feature added to Textsecure. To me the patch by limbus (lImbus@376b228) looks rather unintrusive and straightforward. Any objections by @moxie or @mcgintry against merging it?

@lImbus, any reason why didn't you add this as a pull request to Textsecure yet?

@lImbus
Copy link

lImbus commented Sep 12, 2014

@mejo- The reason I did not pull request this is that I can only confirm that it compiles. I failed to verify the functionality because I failed to register my second mobile phone with Textsecure. Then suddenly, the weekend was over :/
If it still helps with procedures, I am happy to merge master into my branch and try to create a recent pull request, with the restriction that this is untested.

@agrajaghh
Copy link
Contributor

@lImbus If you would submit a pull request I would help you testing/debugging it

@mejo-
Copy link

mejo- commented Sep 12, 2014

limbus, I just realized that you patch would set the whole thread as unread, which seems useless or at least an uncommon feature to me. I'll try to develop an own patch fixing that, test it and provide a pull request.

@mejo-
Copy link

mejo- commented Sep 12, 2014

It seems to me like textsecure doesn't store per-message read-/unread status. At least that's my assumption after a first look into the code. I only found functions that return/modify the READ bit for threads in the textsecure database, nothing that indicated such a value for messages.

It would be awesome to have some documentation about the database schema of textsecure DB. Are any docs available? @agrajaghh, maybe you can help me here?

@tinloaf
Copy link
Contributor

tinloaf commented Sep 12, 2014

Yes it does. Check MmsSmsDatabase.getUnread() and PushDatabase.getPending() ...

@agrajaghh
Copy link
Contributor

@mejo- I don't know of any DB documentation, but you can get the db files with adb and just look into them.

But do we really want to mark single messages as unread? Isn't the purpose to look at a whole thread again to answer it later? I guess marking the whole therad as unread is much easier, no?
There could be a menu option in the therad to mark it unread and a long press option on an thread in the conversationList activity.
Otherwise we need a message specific option (long press on a single message?).

@tinloaf
Copy link
Contributor

tinloaf commented Sep 12, 2014

@agrajaghh Marking the whole thread unread will screw up any unread counter, because they are counting messages. I'd vote for just marking the last message in a thread as unread..

@mejo- The MmsSmsDatabase has a "READ" attribute...

@agrajaghh
Copy link
Contributor

@tinloaf okay, didn't know that. So marking the last one is sounds like a good idea

@generalmanager
Copy link

@agrajaghh @tinloaf The message-specific implementation is favorable because you can jump to the first unread message upon opening the thread. This is very useful in group conversations which have been going on without all the members regularily checking their Inbox.
AFAIR this feature was also favored by either @mcginty or @moxie0 in some related discussion (not sure if it was on the mailing list or on github).

@mejo-
Copy link

mejo- commented Sep 12, 2014

I would prefer to mark single messages as unread as well. And I would suggest to add the option to ContextMenu (with selected message) instead of default Thread Menu.
What I don't get yet is the relationship of read bit for messages and threads in textsecure. That's why I asked about the database documentation. Would it be enough to set read bit to 0 in sms/mms database? In that case, here's a first patch (yet to be tested): https://github.com/mejo-/TextSecure/commit/8080a1a3a65f6d2ea462a18101556764460747eb

@tinloaf
Copy link
Contributor

tinloaf commented Sep 12, 2014

No, marking the messages read could not be enough. In fact, the thread has its own read-flag, you should set both to zero. I wonder why that is though...

@mejo-
Copy link

mejo- commented Sep 12, 2014

After some further tests I don't see a usecase for marking individual messages as unread anymore. With current textsecure design, there's no UI-level indicator for individual unread messages anyway. All you see is a count of unread messages and the highlighted thread with unread message(s).

So if tinloaf is right and marking a whole thread as unread results in screwed up count of unread messages, then the following would be the best approach in my eyes:

  • add the 'mark unread' option to thread menu (instead of context menu for inidividual selected message)
  • mark the last remote message in thread as unread when the menu option is selected
  • still unclear: is it required to mark the thread as unread nevertheless (like tinloaf suggested)?

If you agree with that then I would try to implement it and prepare a pull request within the next days.

Sorry for possibly dump questions. The textsecure codebase is pretty new to me.

@agrajaghh
Copy link
Contributor

I guess @moxie0 or @mcginty can clarfiy this?

@generalmanager
Copy link

@mejo- I don't think this is the best approach. If you quickly check in on a (group) conversation with a lot of new messages, but don't have the time to read them all, it's certainly better to be able to mark everything from a certain message on as unread.
The discussion I mentioned in my previous post was about the the UI implementation of unread messages and IIRC either @mcginty or @moxie0 mentioned that he preferred to automatically show to the last unread message instead of the last message received.

This may not be implemented yet, but to future-proof your PR the behaviour for normal unread messages and messages which have manually marked unread should be identical.

This is not possible if you only mark the last message of a thread or the whole thread unread.
You will either have to mark a single message unread or mark the specific message unread and all following messages too.

I prefer the variant where only one message is marked unread, because it improves the UX for more usecases.
There are lots of different usecases, two of the more regular ones I can see are those:

  • The user receives a lot of notifications and checks into a thread, but doesn't have time to read them all. If I didn't get it wrong, TextSecure will (in the future) show the first unread message first. Thus the user has to mark the first message s/he wants to read later, because many messages were automatically marked unread, when the thread was openend and the user scrolled down to check how many messages there are. Unless a "jump to the next unread message" button is ever implemented (which is very unlikely because of the "don't add new settings/buttons policy"), this scenario should work well with both methods.
  • The user marks a certain message unread because s/he wants to be able to quickly look up the information in this message. For example addresses, room numbers, meeting times, phone Numbers, flight numbers, names of conversation partners and so on.
    In this case the user only wants to read one message later, not the message and all following messages. Thus the implementation should be to mark only single messages as unread.

@jonathancross
Copy link
Contributor

Hi All, any progress on this? It's been almost a year. ;-)
Enthusiastically waiting for this feature.

@moxie0
Copy link
Contributor

moxie0 commented Sep 2, 2015

I'm skeptical that we want to do this. I think this use case should be covered by inbox/archive when we do that instead.

@jeremymasters
Copy link

Seems like a "reminder" capability is the real desire here and the inbox idea lends itself easily to that.

@mcginty mcginty removed their assignment Nov 16, 2015
@svrnwnsch
Copy link

Maybe it is just me, but I don't use the archive function at all.

My usecase for unread messages would be the same as I use it for emails. I read the message but don't have time to answer immediately so I would like to mark the Thread/Message (I don't care which) as unread to later answer it.

I hope this will be added to Signal as for me it is a fundamental feature which is still missing.

@signalapp signalapp deleted a comment from colans Nov 14, 2017
@tmanaud
Copy link

tmanaud commented Jan 17, 2018

I would love to see this "Mark as unread" feature, either thread or individual message.
As this is the way I manage my emails too.

@automated-signal
Copy link

GitHub Issue Cleanup:
See element-hq/element-web#7598 for more information.

@signalapp signalapp locked and limited conversation to collaborators Apr 2, 2018
@jlund-signal
Copy link
Contributor

This feature request is being discussed and tracked here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests