Not sure if this is a bug or not; hence I posted it here. Since I have more than 100 feeds in my setup, I am searching for a specific word in those feeds, and I have subscribed to the search feed (hope that makes sense). My question is; even though I have read everything in said search feed (or have marked as read), when it detects a new item it makes everything unread again.
Is that expected behaviour or a bug? And if it’s how it’s supposed to look, could I somehow mark read items in that feed as read permanently?
tbh it’s a bit obvious why this happens if you think about it
you subscribe to a feed matching keyword X on your own system, importing the articles matching keyword X, thus contributing to search results of the keyword X
I know; hence I wasn’t sure whether to file this as a bug or a feature. You see, I upgraded my tt-rss version a couple of days ago (had an older one from mid last year, guilty as charged) and this behaviour is new; it used to not do this. So I don’t know whether it used to be a bug, and it was fixed, or if it was working normally and now it isn’t
Could it be that before it was searching only unread posts in my feeds, but now it searches everything? Just thought of that.
i suggest a different approach: make a filter assiging labels to stuff with needed keywords instead, that would solve the actual problem without adding pointless stuff to the database.
Could it be that before it was searching only unread posts in my feeds, but now it searches everything? Just thought of that.
you can but it’s not gonna help because your newly imported posts are going to be unread.
you can also force syndicated feeds use original GUID (like it used to work before) but it won’t help either, because they’ll get filtered by duplicate checking and you’ll end up with an empty feed.
it could’ve worked before if your version was sufficiently old but going back to this behaviour now is impossible for variety of reasons - mostly the changes which could affect these were made while allowing new plugin functionality.
i think at this point it would be better to document this behavior in the wiki instead of trying to add some hacky workaround which i’m not even sure how to do tbh.
