Long term whisper posts on topics?

AI-generated summary

Long term whisper posts on topics

The discussion revolves around the issue of “whisper” posts at the end of topics causing users to be unable to mark them as completely read. DeanMarkTaylor noticed this issue and suspected it might be a bug. sam deleted two whispers, but the issue persisted.

Mittineague suggested a workaround by going to the Unread tab and dismissing topics after reading them. However, DeanMarkTaylor pointed out that the “dismiss” operation can be problematic, as it can dismiss unseen topics created between loading the unread topics list and confirming the dismiss.

cpradio revealed that there is already API-level support for passing topic IDs with the dataset, but this feature is currently only available to staff. DeanMarkTaylor emphasized that even “dismiss all” should pass IDs, and ideally, both topic and post IDs should be passed to ensure accurate dismissal.

Mittineague suggested testing whether dismissing a topic would update the “last seen” to include the whisper post. After testing, Mittineague found that dismissing the unread topic did not reset their Watch status.

sam announced that the issue has been fixed, and whispers are no longer an experimental feature. However, there is an edge case where unread counts might be higher than expected, particularly when there is a whisper or deleted post between the old highest read post number and last visible post number.

There has been a couple of topics stopping me from getting to Unread inbox zero…

There are a couple of topics above which are standing between me and :unicorn:

I just wanted to check it is “whisper” posts at the ends of these topics that causing me to unable to “read” these completely and not a “bug”?

https://meta.discourse.org/t/dfp-id-dfp-codes/36574/14?u=deanmarktaylor

https://meta.discourse.org/t/sharing-image-posted-on-discourse-to-facebook-didnt-display-a-thumbnail/37171/10?u=deanmarktaylor

Deleted 2 whispers…

I do want to solve this, but it is very tricky cause we would need to carry around 2 tracking states per topic and amend a pile of queries.

4 „Gefällt mir“

Just wanted to make sure it wasn’t part of some other bug…
… I was noticing odd Unread counts - I assume this was whisper posts at the ends of topics coming and going.

1 „Gefällt mir“

The easiest work-around is to go to Unread, and when you’re sure you have read (all that you can) Dismiss the topics.

I’ve been doing it for a long time now and it does work.

1 „Gefällt mir“

I was aiming for checking there wasn’t bug in the topic / post reading logic.


However this might actually be considered a bug…

I consider “dismiss” a “dangerous” operation from a users reading point of view…

In so far as you can “dismiss” topics you haven’t seen yet.

Topics or posts have been created in the between loading the list of unread topics and confirming the dismiss can be incorrectly dismissed.

Yes, possibly a small window - but with users leaving browser windows open for days now - it might be bigger than you first think.

In the same way as a delete operation takes the exact topic / post ID’s and passes those to the server “dismiss” should so the same…
… only dismissing those topics that were in the view when the user selected “dismiss”.

Currently it just passes:

So no ID’s - meaning - everything is dismissed regardless of if the user was aware of it or not.

4 „Gefällt mir“

Actually there is already support for this. topic_ids can be passed with the dataset, per

However, only Staff have the ability to select topics using the selection tool menu thing on the topic listings. Might be worth opening up that ability to all users? (which may be a feature request)

Here is the two related form datas (using the topic selection tool, then without said topic selection tool).

3 „Gefällt mir“

API level support is great … but to be clear - even “dismiss all” should pass the ID’s.

And really to be absolutely sure you are dismissing the right state, both the topic ID and post ID of a topic should be passed.
Your view of the last known poster may impact your decision to dismiss.

3 „Gefällt mir“

Hmmm that gives me a thought.

I can’t test it now as of the last upgrade my dev set up is broken.

But next time it happens I’ll try it. i.e.

Dismiss, then revisit the topic and Track / Watch it.

That is, will Dismiss “move” the “last seen” to include the whisper post.

1 „Gefällt mir“

I was getting the persistent unread for this topic (I Watch the plugin category)

https://meta.discourse.org/t/event-signup-sheet-plugin/40822

I Dismissed it.

When I went back to the topic I was still Watching it.
Dismissing the unread did not reset my Watch

1 „Gefällt mir“

This is now fixed per:

https://github.com/discourse/discourse/commit/33d0a23d84a4d22f28b33a44df67dee1d14c35a0

Whispers are no longer an “experimental” feature.

There are a few notes though:

If you have an old system where you had “experimental whispers” enabled and were using them make sure you run:

./launcher enter app
rails c
Topic.reset_all_highest!

There is an edge case I will work on fixing where unread counts are higher than what they really are. In particular, if there is a whisper (or deleted post) between your old highest read post number and last visible post number on topic. I have an idea on how to fix but it is not a show stopper.

8 „Gefällt mir“