Page 1 of 1

ALLOW_DUPLICATE_POSTS Feature

Posted: 25 Feb 2016, 14:29
by DigitalDJ
Hi,

I've only just realized that this feature no longer exists in TT-RSS. Reviewing the GitLab code it seems it was recently fixed...then removed...but is there a reason for this?

Some time last year this feature broke, and I remember I submitted a pull request on Github to fix it.

At the time, I remember fox was contemplating on removing it, but I provided some reasoning to keep it around. I definitely use it...but I guess I'm minority.

The reasoning was as follows:

Have a main RSS feed that contains all articles for a particular site, but there is a second RSS feed that contains Top 50 posts from the same site. There are therefore duplicate articles, but having the two feeds helps churn through most interesting posts on days where the feed is very busy.

Can we get this feature back? Was it removed just because it made things too complex?

Cheers

Re: ALLOW_DUPLICATE_POSTS Feature

Posted: 25 Feb 2016, 14:56
by DigitalDJ
If it isn't coming back, here's the patch for those that want it.

ALLOW_DUPLICATE_POSTS.patch
(2.16 KiB) Downloaded 155 times

Re: ALLOW_DUPLICATE_POSTS Feature

Posted: 25 Feb 2016, 15:09
by fox
there are multiple UI issues with articles having the same internal database ID which make the whole thing kinda confusing so I removed it

Re: ALLOW_DUPLICATE_POSTS Feature

Posted: 25 Feb 2016, 15:14
by DigitalDJ
fox wrote:there are multiple UI issues with articles having the same internal database ID which make the whole thing kinda confusing so I removed it


Could you elaborate on the issues, so I can look into them?

Are you referring to star / read counts? e.g. If you star a duplicate item the count is not accurate, and if you read a duplicate article it will read it in the other feed also?

Are there other UI elements to consider? I'd rather work on these and try and get these features back than just removing it altogether.

Cheers

Re: ALLOW_DUPLICATE_POSTS Feature

Posted: 25 Feb 2016, 15:33
by fox
you click on a thing (or use a batch operation) and suddenly multiple things get marked as read

shock, horror, ensues

e: a lot of things are processed by ttrss_entries.id, rewriting everything to use user_entries is possible, i guess, but definitely not worth it, and even if someone bothers, i'm not going to merge the humongous patch resulting in this valiant attempt

a different possible solution is treating articles independently i.e. include feed_id into guid when duplicates enabled or something like that to escape the multiple user_entries -> one base entry scenario