[BUG]: If title of article changes, the article adds as new one

[sakkamade]

Brief description of the issue.

When certain article has already been fetched and this article's title changes, a separate article with changed title appends to the list as new entry.

How to reproduce the bug?

1. E.g. copy the link from Atom topic feed at the bottom of bbs.archlinux.org page (or any similar)
2. Fetch it through RSS Guard
3. Wait until it gets [SOLVED]

What was the expected result?

The title of already existing article to be amended.

What actually happened?

Identical (or slightly distinct) article with changed title is being added to the list.

Other information

Akregator is capable of it.

I guess the criteria of such filtering (whether to add new entry or amend already present one) is being the link to the article, which stays invariant.

• OS: Arch Linux, KDE
• RSS Guard
  Version: 4.0.0 (built on Linux/x86_64)
  Revision: 0299308
  Build date: 16/07/2021 06:16
  Qt: 5.15.2 (compiled against 5.15.2)

[martinrotter]

@sakkamade You are right. There was lengthy discussions about this some many years ago and it was problematic.

Here is the code.

Firstly, some feed types have special ID which uniquely identifies the article and stays the same if (for example) title changes but still describes same event (for example):
https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.6
https://validator.w3.org/feed/docs/rss2.html#hrelementsOfLtitemgt
https://jsonfeed.org/version/1.1

RSS Guard idenitifes the article as "the same" if it has same URL and (at the same time) TITLE and AUTHOR. IDs provided by the feed are not taken into account (for synchronized services like TT-RSS this is different). I remember that this state was de-facto result of "that" discussion we had with some users in RSS Guard prehistoric times and maybe it is time to re-do it.

Thing also is that many feeds do not provide IDs for their articles.

So basically we can choose from:

1. If article provides ID, then use that ID as unique idenifier.
2. Do not take TITLE of article into account when comparing them for uniqueness.

And/or I could enhance "message filtering" mechanism to be able to:

• find existing article (and potentially overwrite it directly) in RSS Guard's DB with input parameters (URL OR AUTHOR, etc.) and return its data (useful in cooperation with 1. - you could "generate" IDs for articles which do not have them, for example use their URL as ID, or you could change title/author/whatever directly in the DB if article is already there, ...,

There are many options, too many.

[sakkamade]

some feed types have special ID which uniquely identifies the article

Source on it, or sample of how it looks? For I am not quite sure I have ever seen it.

---

So basically we can choose from:

1. If article provides ID, then use that ID as unique idenifier.
2. Do not take TITLE of article into account when comparing them for uniqueness.

For myself, I would prefer #1 and

... enhance "message filtering" mechanism ...

However, at the same time, I cannot come upon an example of situation where user will actually benefit from it.
It might appear as mere obstacle, or roundabout route, in most cases.

So the second would be for best, I guess?

[sakkamade]

some feed types have special ID which uniquely identifies the article

Source on it, or sample of how it looks? For I am not quite sure I have ever seen it.

Never mind. Most (every single?) of the feeds have it. In every feed I see, it contains the link on the article.

Now I see what you mean.
And now I am of opinion that #1 is the best option.

[martinrotter]

@sakkamade

But note that "guid" does not have to be URL. It can be just about any string, but is URL in many cases indeed.

Yes, other feed readers usually utilise "guid", I will try to make proposed changes.

[martinrotter]

ok, pushed the change, feel free to test with latest devbuild

[martinrotter]

@sakkamade The change proved to be more difficult than I anticipated because "ID" of message is used on many places throughout RSS Guard (particularly in cooperation with synchronized services) so I had to specially take care of some corner cases, hopefully it will work out nicely.

Let's give this change some time, report any associated bugs here.