Is there a way to hide entries that are not relevant without having to mark them as read?

[lucianolacurcia]

How is the workflow of using miniflux?

I add my feeds, and then a bunch of new entries appear. I want to go through them and discard the ones that are irrelevant, read the ones that I want to read and also keep the ones that seem interesting for reading later.

Is this the intended way or I am using it incorrectly?

I don't understand how can I mark any entry as "read later", or delete the entries that are not interesting and I wont read from the main feed.

Thanks!

[fguillot]

I personally use the mark as a read feature to discard all the entries that I don't want to read, either with keyboard shortcuts or touch gestures on mobile. Then I read what is left. I bookmark the articles that I want to read later.

Sometimes, I just read a few interesting articles, and discard everything else by marking all articles as read.

In my case, the actual "mark as read" feature is more like "I'm not interested / discard".

I'm thinking more and more about changing this flow in Miniflux since RSS feeds are a constant flow of new articles. But that might be for the next major version of Miniflux.

[lucianolacurcia]

I think it would be a good improvement, for me is important to know what I read, what I like, what I want to read and hide or archive what I wont read.

When are you planning to start the development of the next major version? I would like to contribute

[lucianolacurcia]

Yep, definitely a "discard" button is needed. I need to know what I already read and what i don't.

Besides of this, thanks for your project, I am using a lot!

[danielyrovas]

would 'archive' also work?
Rather than discard, it is simply a flag which is hidden by default.

[fguillot]

There are similar issues opened in the past about this topic: #1285, #1567, #784, and maybe more.

Internally, Miniflux has currently 3 entry statuses read, unread, and removed.

The status removed could be called hidden or archived. Those entries are not visible in the web ui.

There are certainly different ways to solve this. I need to think more about it...

The first thing that comes to my mind is to have a new action "hide" in the web ui that allows people to change the entry status to removed. It might be the most simple solution to implement (Avoid major refactoring and database schema change).

The read later feature could be handled like the bookmark/favorite feature.

[lucianolacurcia]

Any progress on this?

[shizunge]

If we firstly add a new statue e.g. either marked or viewed or a new column to the database schema, then other developer can play with it with their own database, without worrying compatibility with future miniflux version. In the future miniflux version, we decide how to use the new status to differentiate entries.

Normal user won't notice the difference with the new statues in the database, because no entries should go to the new status in the production release.

[ztec]

I want to add to the discussion a new kind of status in addition of the ones you mentioned. in_progress
This would be an entry that we started to read but not finished yet. I mostly think of this status for podcast where you can start listening to it, then come back later to finish it.

I'm analyzing a way to implement #1847 and the concept of in_progress entries poped-up as a good idea.

In addition to the status, we could also save some "reading" metadata such as enclosure playing position (already done) and scroll position (not done).

What are the impact of adding a new EntryStatus ? It feel like it would not be to much of an issue on miniflux itself. Maybe on API users not expecting this new potential value in the API. (this could be mitigated by rewriting it to another status)

[lucianolacurcia]

I think its a good idea to have an in_progress status