Currently, if you mention an object on another object (like mentioning T123 in a comment T456), we permanently write a timeline story on the mentioned object ("alice mentioned this on Txxx.") and create a permanent "mentioned" relationship. This relationship is append-only, so if you later edit your comment to remove the mention in the comment text, that does not unpublish the story or revoke the relationship.
In both PHI1496 and PHI1602, users mentioned some objects by mistake and wished to undo these relationships later.
There are two general concerns with this: a product concern that undoing things is generally confusing, and a technical concern that it's currently hard/expensive/impossible to undo them anyway.
On the product concern:
"Mentioned" currently means "was ever mentioned", not "is currently mentioned". [P]art of it is for consistency and so that mentions don't vanish after users make edits. For example, if you're looking at some other object and see "alice mentioned this on Txxx." in the timeline for that object, it's potentially either confusing or inconsistent if a later edit to the mentioning task can remove the mention ("confusing" if the timeline story vanishes and you aren't sure why; "inconsistent" if the timeline story sticks around and still shows the mention, but the mention list updates and removes the mention). There are no other cases today where a timeline story can vanish (outside of explicit object destruction with bin/remove destroy).
On the technical concern:
[T]he technical change to make this mean "is currently mentioned" isn't straightforward, either. Consider and object with a large number of comments (say, 5,000 -- maybe this is a Conpherence chatroom, or a task with a lot of bot activity). If I add another comment which mentions T123, then edit my comment to remove the mention of T123, we can't just remove the mention relationship: it's possible one or more other comments also mention T123. We'd have to load all 5,000 comments and reprocess them to see if any of them mention T123, or store the relationship in a reference-counted way, or change the relationship to be a field-level relationship between particular blocks of text and remote objects. All of these approaches involve additional complexity -- for example, blocks of text do not have PHIDs, and a given object may have multiple blocks of text which can trigger mentions (Revisions have both "Summary" and "Test Plan").
PHI1602 raises the difficulty further: the mentions were in a custom field.
Setting aside the product concern, we can address the technical concern by making each mention store the field where it appears (for example: the summary, or comment X, or custom field Q, and tracking mentions on a field-by-field basis. When a particular field is edited, we can safely remove mentions attributed to that field which are no longer present.
I suspect we shouldn't actually undo the mention or story, but the UI could change to look more like this:
Mentioned in Summary:
- T123
- T456
Mentioned in Comments:
- T789
(9 other tasks were previously mentioned on this object. Show Outdated Mentions)
Mentions are currently stored as edges, and we can't reasonably fit the additional data required by field-level tracking into the edge schema. T13419 and/or T13056 may make some aspects of this easier. I suspect the path forward is just a custom table, but perhaps that custom table can be the same as the table probably implied by T3577.